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In this Issue 

Not everything that gets transmitted over a data communication network 
is data. Each block of data is surrounded by synchronization characters and 
is usually followed by error detection bits. Between blocks of data there are 
overhead transmissions necessary to initiate, maintain, and terminate com- 
puter transactions. Each network uses a particular protocol which Is a def- 
inition of the synchronization and control characters and the format of data 
blocks and control messages. Each network also uses a particular data 
^gr code. FortunateEy, the number of protocols and data codes isn t as large as 

the number of networks. There are a handful of standard protocols and most 
networks use one of them. The same holds for codes. 

When there's trouble on the network, it Isn't necessarily a hardware failure, and its effect might 
only be observable as a deviation, perhaps intermittent, from the required protocol. Protocol 
analyzers are instruments that are specially designed to monitor in-service data communication 
lines, trap errors, and provide enough information to isolate the source of an error to an individual 
component of the network. This issue gives you the design story of two Hewlett-Packard protocol 
analyzers. The HP 4953A, the subject of the articles on pages 4, 12, and 18 ; is for analyzing 
high-speed networks and is used mainfy at computer centers, although it can also be used in the 
field. The HP 4951 A, described in the article on page 24, is a lightweight, portable, field sen/ice 
analyzer for medium-speed networks. Bolh analyzers are capable of not only monitoring but also 
simulating data transmissions. This makes them useful for checking components of a network 
individually, or for verifying the operation of a component before its installed in the network. Both 
analyzers are also capable of remote operation. One HP 4953A Protocol Analyzer can control 
and receive data from several HP 4953As or HP 4951 As at remote sites. This means that one 
engineer or technician can test an entire network from a central site. Our cover illustrates this 
capability. Two special HP 4951 A features help the field service technician: Autoconfkjure deter- 
mines the network's protocol and data code automatically, and bit error rate testing can eliminate 
the need to carry a separate instrument for this purpose, 

Hewlett-Packard's Semiconductor Productivity Network (SPN) is a group of integrated modules, 
primarily software, that are designed to automate the production of integrated circuit chips. The 
aim is to keep the yield of good chips high by correlating data from the entire factory to minimize 
yield fluctuations and discover their causes. By far the most important part of the operation is the 
process equipment, where temperatures and chemical concentrations are so critical that their 
control has always been something of an art. In the article on page 30. you'll meet the SPN 
module called PC-10. which is designed tor direct monitoring and control of process equipment 
such as furnaces, ion implanters, and plasma etchers, as well as monitoring and measuring 
equipment, The outgrowth of work begun at HP's central research laboratories (see "A. Process 
Control Network" in our June 1981 issue), PC-10 improves the repeatability of the production 
process, providing the predictability needed to get yields up and keep them there. 

-ft ft Dofan 



What's Ahead 

In August, well have an article on the objectives and basic principles of HP's next-generation 
computers, which are now under development. Four articles will cover the design of the HP 3326A 
Two-Channel Synthesizer, a signal generator that produces either a pair of independent signals 
or a complex combination of two signals in the frequency range of dc to 13 megahertz. Another 
article will discuss TC-10, a module of HP's Semiconductor Productivity Network (like PC-10 in 
this issue), TC-10 takes data from various incompatible sources and makes it accessible wherever 
it's needed. 
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A Protocol Analyzer for EDP Centers and 
Field Service 

It 's the latest member of a family that also includes a iow- 
cost portable analyzer for field service and a high-speed 
BASlC-programmabte analyzer for data communications 
research and development. 

by Aileen C. Appleyard, Roger W. Ruhnow, William Grant Grovenburg, and Wayne M. Angevine 



THE DEVELOPMENT OF COMPUTER NETWORKS 
has led to the need for reliable data communications, 
not only between elements of the network such as 
terminals and the CPU, but also between networks — lor 
example, between several computer systems and a main- 
frame system. 

Since these systems mav not be al a common site, data 
needs to be transmitted from one site lo another, This can 
be done using either dedicated lines or data networks. For 
two systems to exchange data, the data must be in a com- 
mon format for both systems, and must contain overhead 
information — for example, the address of the unit to which 
the data is to be sent, what type of data is being sent, and 
error checking informal inn, It is usual for the receiving 
system to transmit an acknowledge message in response 
to information received so that if some data is Inst in trans- 
mission it can be retransmitted, 

OS1 Model 

Networks are structured in levels, each level having a 
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specific function. One commonly used method of structur- 
ing B network is the ISO Open Systems Interconnection 
model, which has seven levels, as shown in Fig, 1. 

The physical level transmits the digital data over the 
physical communications link* For example, the standard 
RS-232-C link uses a voltage of less than — 3V for a mark 
(logical level one) and greater than I 3V for a space (logical 
level zero). Other commonly used physical layer standards 
are RS-449 for systems operating at higher data rates, and 
X.21 t which is commonly used in Europe on public data 
networks. 

The function of the data link level is lo ensure that error- 
free data is received at the network leveL This is achieved 
by partitioning the data into frames which are transmitted 




Fig, 1 , tn the ISO Open Systems Interconnection (OSI) model, 

networks have seven layers. Communication takes place be- 
tween tike tayers tn different systems 



Fig. 2. The Hewlett-Packard family of protocol analyzers in- 
cludes (top to bottom) tne HP 4955A, a 72-kbps BASIC-pro- 
grammable analyzer for datacom R&D, the HP 4951 A f a 19.2- 
kbps low-cost portable analyzer for field service, and the HP 
4953A, a 72-kbps analyzer for field service ana dataccm 
center applications. 
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sequentially, and requiring a frame acknowledgment signal 
from the receiving system. U this signal is not received 
within a fixed time, the frame is retransmitted. This level 
also controls the rate of frame transfer, so that systems 
operating at different speeds can exchange data. 

The network layer combines frames into larger groups 
known as packets and routes the packets to their destina- 
tions- This route would be fixed in a staple network, but 
in a more complex network the routing would vary accord- 
ing to system loading. 

The transport layer accepts data from the session layer 
and splits it into smaller units for efficient transmission to 
the network layer. It also isolates the session layer from 
any impact of hardware changes in the system. 

The session layer is the user's interface to the network 
The user establishes a connection with a process on another 
machine in this layer, and billing information is contained 
in I his layer, 

The presentation layer performs text compression, en- 
cryption, and file conversion functions. 

The application layer's function is determined by the 
individual user and typically is used to control the interface 
of two user programs on different machines. 

Protocol Analyzers 

The HP 4U55A, HP 4953 A, and HP 4951 A Protocol 
Analyzers (Fig, 2) have been developed to aid in the design 
and maintenance of these networks. 

The HP 4955A is primarily used in data communications 
research and development, where the features of high- 
speed operation to 72,000 bits per second and the BASIC 
programming language are required, The HP 4953 A is used 
in the high-end field service area and in EDP centers, where 



speeds of 72,000 bits s may be required, but in a less expen- 
sive and more portable instrument. The HP 4951 A is used 
in field service, operates to 19,200 bits s* and is a low-cost, 
easily portable instrument. 

This article and the articles on pages 12 and 18 describe 
the capabilities and the design of the HP 4953A Protocol 





Fig. 3. The HP 4953 A Protocol Analyzer connects 10 the net- 
work under test through a network-specific interface pod. fl 
has a menu -driven sottkey user interface and a buitt-in car- 
tridge tape unit for reading and storing data and applications 
programs. 



How Protocol Analysis Can Help 



A problem situation that occurred at HP's Colorado Telecommuni- 
cations Division illustrates how the HP 4953A Protocol Analyzer 
can be used to diagnose data communications difficulties When 
a file was to be printed from an HP 3000 Computer, the response 
lime of Ihe printer was very slow. A line woufd be printed, then 
there would be a wa=t of several seconds before the next line 
was printed, which was unacceptable 

An HP 4953 A was installed to monitor the activity between the 
HP 3000 fDCEJ and fhe printer (DTE) during printer dump 
routines. It was discovered that the DTE was not returning an 



acknowledge character AK in response to the enquiry character 
EQ sent by the DCE This was causing a timeout of the DCE of 
two seconds before the next block of lexi was sent to the DTE, 
This was measured using the HP 4953A's CUfSOr liming feature. 

To verify the problem, the HP 4953A was then configured to 
simulate the response of the DTE (Fig. 1). The printer dump 
routine was run with no timeouts occurring The time from eq to 
the start of the next block of text from the DCE was only four 
miNiseconds r and the time to print a page ot text was reduced 
by 59%. 
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Fig. 1. Simulate menu. 
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Analyzer, the newest member of the family (Fig. 3]. The 
HP 4951 A is described in the article un page 24. Most 
opftraliunal characteristics are common to all Ihree analyzers. 
For example, all three instruments use the sEirne menu- 
driven softkey approach in guiding the usei through I he 
selections necessary for correct operation. 

A protocol analyzer has two main functions: to monitor 
data and to simulate data. In the monitor mode, the analyzer 
decodes (hi In either from the internal buffer memory or 
from B Jim- and displays it in a readily understandable 
format. Data in the internal buffer may have been stored 
there at an earlier time or transferred there from a DClOO 
cartridge tape. Data may be stored to tape and subsequently 
analyzed on any of the instruments. 

The Setup menu is used to establish the characteristics 
of the system being used, including the protocol, the data 
rate 1 the data code, and the error checking scheme, These 
are all parameters that are defined by the network under lest. 
The HP 4953 A is able to operate with the SDLC, HDLC, X.25, 
X.75, SNA. DDCMP, Bisync, and asynchronous protocols. 

The Monitor menu allow T s programs to be written to trig- 
ger the start and slop of the display and storage functions so 
that a large quantity of irrelevant data need not be scanned. 
For example, one of a group ol terminals may not respond 
lo data from the mainframe. This particular terminal's data 
iluw can be examined by triggering on the address of I ha I 
terminal and examining the data after this address. There 
are also five timers and counters, which can be used to 
select data to store or display — for example, by storing data 
to tape for a specified time after n trigger event or after a 
selected number of specified events (see Fig. 4). 

The Simulate menu allows the user to select whether to 
simulate a DTE (Data Terminal Equipment) — for example, 
a keyboard or computer — or a DCE (Data Circuit-Terminat- 
ing Equipment) — for example, a modem — and whether the 
transmission is to be full or half duplex. Programs are then 
written using the soft key-directed syntax to generate data 
in the format of the selected protocol and transmit it via 
the analyzer's interface pod to the line (Fig, 5). The leads 
of the interface pod can lie set to simulate hand shake se- 
quences between DTE and DCH, and data strings can be 
specified so thai a complete message can be transmit led. 

The Display menu allows several different display for- 
mats to he selected depending on the protocol, so the user 



can easily look at the data of interest. DTE data, DCE data, 
or both can be shown on the display and, if required, the 
data can be separated into columns to decode the protocol 
header functions. In addition, data may be shown in con- 
junction with the logical stale of selected interface leads. 

The Run menu is used to execute the selected Monitor 
or Simulate menus. In the monitor mode it lets I he user 
select the source of data, eilher on-line or iroin I tie internal 
data buffer, and in the simulate mode the analyzer is either 
allowed to free run or made to stop when I he buffer or the 
tape (if selected] is full. The Execute key in this menu starts 
the analyzer running. 

The Examine Data menu allows detailed analysis of the 
data that has been stored in the buffer using the selected 
monitor menu. In this mode it is possible to perform timing 
measurements between characters in the display. 

The Mass Store menu allows control of the DClOO tape 
unit. The tape can be used to store buffer data and ils 
associated menus, nonstandard data codes, and application 
programs. 

The Printer menu allows the screen to be prinled to an 
RS-232-C ASCII printer. Both menus and buffer data can 
be printed. 

The Remote menu allows configuration of the HP 495 3 A 
as either a controller of up to 16 slave instruments or as a 
slave. After the configuration of the remote system, the 
operation lo be performed remotely is selected, Functions 
available are uploading and downloading of data and 
menus and application modules. The HP 4953 A may con- 
trol or be controlled by an HP 495 1 A or an HP 4955A with 
certain limitations. 

The Application menu is used to load and execute appli- 
cation programs written for the instrument. Typical pro- 
grams include additional protocol decodes. I ape edit pro- 
grams, and high-level emulation programs that cause the 
instrument to simulate a network. 

The Extended Tests menu is used for troubleshooting 
the instrument and directs the technician to a problem area. 

Remote Operation 

The features of the HP 4953 A suit it to troubleshooting 
problems in data communications. These problems might 
arise from improper configuration of hardware or software, 
or from the failure of hardware components, The envirnn- 
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ment may be an exisl ing. system, an expansion of an existing 
system, or an installation of a new system fn mosl cases, 
the first person to troubleshool tin? system will not have 
an extensive data communications background. Most 
likely, the troubleshooting procedure will be confirmation 
L>j software <iii( 1 hardware configurations and confirmation 
of hardware integrity. If these procedures are unsuccessful, 
then a system specialist or data communications special! si 
must get involved. 

The specialist needs to examine the activity on the com- 
munication link. Tools available mi^ht include diagnostic 
trace listings provided by one uf the communicating de- 
vices and/or protocol analyzers. Unfortunately, the data of 
interest is not immediately available. Either data rnusl be 
collected al the site and delivered, or the site must be 
visited. Either case involves added expense and downtime 
for the customer. If data is delivered Ebtlie specialist, there 
is a danger that the data does not reveal the problem. On 
the other hand, site visits reduce the availability of the 
specialist. The remote feature set of the III' 4Hr»:iA is tail- 
ored to reduce or eliminate these problems 

Using a local HP 4953 A the specialist can remotely c on- 
figure, execute, and obtain data horn a remote III 1 -JU53A* 
All that needs to be done at the remote site ts to ennum I 
the appropriate pod on an HP 495 3 A to the link uudei 



Fig. 5. An HP 4953 A program 

(top) to transmit HDLC SNRM (set 
normal response mode) and the 
resulting display (bottom) 



and attai h I he RS-232-C connector on tin- back panel to a 
leased or switched line via an asynchronous modem, 
matching the bit rate of the port to that of the modem, The 
specialist now has full conirol oi the remote instrument. 
Any number of lests can be run and the results obtained 
for local analysis. 

The remote feature sel of the HI* 4953A allows manipu- 
lation of all basic functions, IVom a controller, the follow- 
ing operations ran be performed on a remote unit [slave). 
Upload and download are defined wilh respect to the con- 
troller, i.e.. a menu is downloaded from the controller to 
the sj 

■ Movement of menus 

P Upload Setup, Monitor, Simulate, Run, arid Display 
menus 

Download Setup, Monitor. Simulate, Run, and Display 
menus 

■ Manipulation of mass storage 
n Slave's mass store catalog 

□ Upload Mass Store menu 

□ Download Mass Store menu 

n Execute slave's Mass Store menu 

■ Movement of data 

□ Upload timers and coun 
( iplnad captured data 
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D Download captured data 

■ Manipulation of applications 

o Slave's application module catalog 

□ Upload application module 

a Download application module 

d Execute slave's application module 

□ Delete slave's application module 

■ Information on slave 

□ Identify slave 
d Slave's status 

d Slave's memory use 

■ Miscellaneous control 

□ Soft reset slave 

p Set slave's buffer size 

D Lockout slaves keyboard 

c Execute slave's Run menu. 

Both point-to-point and multidrop remote con ("i^uraf ions 
are possible, as shown in Fig, 6. In the multidrop configura- 
tion, a controller HP 4953 A can work with up to sixteen 
slaves. A particular slave is selected by an address field in 
the controller's Remote menu. 

Remote User Interface 

The HP 4953A"s user interface is designed to be user 
friendly through the use of softkeys and menus. An HP 
4953A is configured as a controller or a slave depending 
on which Remote menu [Controller menu or Slave menu) 
was last selected. The Controller menu allows modification 
of the remote link da I a rate, selection of the target slave, 
and selection of the desired slave operation- Once these 
selections have been made, the operation can be performed. 
Errors encountered by the controller during execution are 

Poinl to Point 

One slave on a dedicated 

or switched tine 
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Fig. 7, Baste structure of an HP 4953 A application module. 

reported to the user as syslem errors. An example of a 
controller error might be, 'The tape is out," following an 
operation to obtain the .slave's mass store catalog, 

The HP 495 3 A is a slave following power-up. a hard 
reset, or selection of the Slave menu. Once a slave, the 
instrument will respond to commands from a controller- 
The Slave menu allows modification of the remote link 
data rate. In addition, if a user at a slave wants to prevent 
a controller from modifying the state of the slave, controller 
operations can be disallowed via the Slave menu. The slave 
will then return an error for most operations received from 
a controller. 

Remote Implementation 

Remote operations use a half-duplex asynchronous pro- 
tocol that guarantees data integrity across the communica- 
tion link, A transaction sequence is the basic building block 
for remote tasks. There are four parts to the transaction 
sequence. First, the controller issues an operation code to 
the target slave. Second, the controller transfers data to the 
slave if required by the operation. Third, the slave returns 
a completion status to the controller. Fourth, the slave 
sends data to the controller if required by the operation. 
The first and third steps are required, while the second 
and fourth steps are optional. The following three examples 
illustrate these steps. 
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Fig. 6. Two HP 4953^ remote configurations in the multidrop 
configuration, a controller HP 4953 A can work with up to 16 
slaves 



Operation code Data to slave Completion status Data to controller 

Reset remote None Operation accepted Norm 

Upload me-iuis None Operation accepted Menus 

Download menus Menus Operation accepted Nun* 

The slave can reject an operation following the first or 
second step. For instance, if controller operations are dis- 
allowed by the slave and the controller initiates a download 
menus operation, the slave need not wait for the menus 
(step 2) to be received before it rejects the operation. On 
the other hand, the slave could accept lh« j men us [step 2) 
only to find the menus are not compatible with it. If an 
operation is rejected, the reason is always sent to the con- 
troller in step 4. The reason is then presented to the user 
at the controller. 

Some remote tasks, such as the examples above, require 
only one transaction sequence. Other tasks, such as upload- 
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ing an application module, require several transaction se~ 
quences. This a Mows even complex tasks to be im- 
plemented using simpler operations, 

Applications Software 

The data communications test market is a very difficult 
one. The market is very fragmented, with each communi- 
cations equipment vendor using a special protocol or vari- 
ation of a standard protocol To make matters worse, often 
a number of slightly different versions of a protocol exist 
because the standard changes over time. This fragmentation 
makes it impossible to design a completely general-purpose 
protocol analyzer. 

The solution to this problem is applications software. 
An application is a program that is not buiJt into the 
firmware of the instrument, but adds a function to the 
instrument w r hen it is present. By the use of applications, 
thf^ instrument can be customized for a specific new or 
different protocol without the cost and difficulty of a 
firmware change. 

If a system is to be capable of supporting applications, 
some method must be devised to hook the new T software 
modules into the system. Particularly in a softkey-driven 
system like the HP 495 3A t new softkeys must appear when 
an application is present, Even more important function- 
ally, when those new keys are pressed, the new software 
musl be executed. 

A complication peculiar to the HP 4953A is the multi- 
processor architecture (see article, page 12). Applications 
may need to change the functionality of more than one 
processor, This means that there must be a way in which 
code brought into the unit through the system processor 
can be downloaded to and executed on, for instance, the 
front -end processor. 

Fig. 7 shows the basic structure of an application module. 
The first block of data is a header, which contains informa- 
tion such as the name of the application and security flags. 
The header also contains four vectors, which are the offsets 
from the header to four functions within the application, 
These functions handle loading, deleting, reselling, and 
uting the module, The reset vector is called when a 
system soft reset occurs, The execute vector points to the 
top level of the application program if the application is 
executable. The load and delete vectors are discussed later. 

An application may be executable or not. An executable 
application is one that can be run from a softkey in the 
applications menu. A nonexecutable application generally 
adds functionality to an exisling menu, and therefore is 
not executed directly. 

Installing an Application 

The problem of integrating applications into ibe resident 
firmware Is solved ih rough the use of jump tables (see box, 
page 10). The jump tables contain the addresses of every 
major routine in the system. The developer of an applica- 
tion simply chooses the functions that need to be changed 
to display a new suit key or i till a new routine and replaces 
those functions with new versions by changing the entry 
for each routine in the jump table. Fig. 8 shows the replace- 
ment of a function. 

The characteristics of system functions have h i^reat deal 



of impact on the ease of writing applications and the size 
of the applications produced. Good software engineering 
practice requires individual functions to be small and to 
implement a well-defined piece of the solution to some 
problem. These characteristics pay off handsomely when 
an application must modify the solution of a particular 
problem* because fewer and smaller functions have to be 
replaced. 

This is where the load and delete vectors come into play. 
The load vector points to a routine that changes the jump 
table entries as needed by the application, and the delete 



Code 



Function Replacement for Applications 

Jump Table 



(Firmware) 

moduteABC( ) 
( 

intx.y; 

x = function_X( }: 

y = function_Y( J; 
return; 



(Before Application Load) 



function_X( ) - 
< 



(code) 



return (x); 
) 

function. Y( ) 



(code) 



return(y'); 



xxxxxxxx 



yyyyyyyy 



(After Application Load) 



(Application) 
appJunction_X( ) 



-xxxxxxxx 



-yyyyyyyy 



(new code) 



return (x); 



Key: 

» fetch jump 

* pointer to function 



Fig. 8. Application programs change the functions of 
softkeys or caff new routines by changing entries in jump 
tables. 
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Protocol Analyzer Software Development 



Programming in the instrument environment provides oppor- 
tunities that are somewhat different from programming in a main- 
frame environment One of the historic constraints in a ROM- 
based instrument is the amount of cods space available to the 
software designer, although this is beginning to change as the 
cost of memory drops. In the HP 4953A this obviously wasn't a 
severe problem, since we ended up with almost 350K bytes of 
code, but even so r we were beginning to push the limits ot rhe 
available space. This space constraint caused the project team 
to employ slightly different methodologies from those we would 
have chosen given unlimited space and processor speed. 

We realized thai we were developing a large software system 
that would require several software designers. Since the user 
interface was organized as a set of menus, each of whtch was 
relatively decoupled from the others, each designer was given 
responsibility tor a different menu. This resulted in the software 
being partitioned into a set of separately linked modules. This 
separate linkage of the modules in the system decoupled the 
designers from each other and made the possibility of undesir- 
able interactions between modules less likely. In general, each 
module was in charge of modifying a set of global variables, 
which orher modules would use as values but not modify. As an 
example, the Setup menu modifies the protocol specific param- 
eters. The Display, Examine Data, and Run menus use these 
values but do not modify them. The modules range in size from 
1 5K bytes to 45K bytes. As large as some of these modules are. 
they were much more controllable than a single module of 350K 
bytes would have been 

At power-on the kernel module calls the performance verifica- 
tion module, which does a thorough lest of the hardware. Assum- 
ing I hat the hardware is healthy, the performance verification 
code returns control back to the kernel which then calls the 
initialization roulines located in each of the modules. Once the 
machine has been initialized the main-level display ts presented 
and a user response is awaited When the user decides to enter 
a particular menu, control is transferred to the appropriate mod- 
ule Within the menu r the user can modify the parameters as- 



sociated with that menu. For example, modifying Display menu 
parameters changes the way the Examine Data or Run menus 
present the data to the user The changes to the data base are 
usually under softkey control and protect the user from rrus lakes 
A high level of help is provided through this softkey interface, 
since each softkey selection automatically relabels the so ft keys 
presenting the user with the next set of selections. 

Since all of the software designers had a need to access the 
I/O devices of the MP 4953 A. such as the display and the 
keyboard, a standard library was implemented All of the user 
interface software was implemented in the C programming lan- 
guage, so it made sense to provide a C standard library for the 
use of the software designers. Because of the position dependent 
nature of the user interface menus, a superset of pnntf and scant 
was implemented that allowed cursor and attribute control of the 
display Since Ihe HP 4953A allows the user to operate in several 
data codes, such as ASCII and EBCDIC, scant was modified to 
allow the input from the keyboard to be returned in the requested 
data code, The implementation of the standard library allowed 
the software designers to gain command of the I/O functions in 
the HP 4 953 A very quickly, since the commands closely follow 
the conventions established by C 

The design team acknowledged early in the project that a 
system of the size we were developing was highly unlikely to be 
error-free, so the team implemented jump tables through which 
all routines are accessed. These jump tables are located in an 
EPROM by themselves, the theory being that, if and when bugs 
are found, the jump vector of ihe errant routine can be replaced 
with a vector to a replacement routine located in the space left 
in the jump table EPROM, in this way, a field update can be 
effected by replacing only the existing EPROM with a new one 
that contains the updated jump table and the patched code. 

William Grant Grovenburg 

Development Engineer 
Colorado Telecommunications Division 



vector points to a routine that reverses these changes. The 
one major liability of Ibis system is its inability to handle 
more than one application changing a ^iven jump table 
entry at a time. Obviously, if application A is expecting its 
copy of function X to be executed, while application B f 
loaded later, also changes the entry for function X, applica- 
tion A will he gravely disappointed. The system prevents 
this conflict hy not allowing the loading of a second appli- 
cation conflicting with one already present. 

Applications that need to modify the way that data Is 
brought into the analyzer must change the code on the 
front end, w F hich uses a separate processor. Honks are pro- 
vided by the front-end program to allow the application 
code to be downloaded in In the front-end processor's mem- 
ory. This code is then accessed through a command table, 
also downloaded into the front -end processor's memory, 
which replaces the existing table. The command table is 
very similar to the jump tables on the system side. The 
new command table may access any functions nornuJk 
resident in ihe front end as well as new functions defined 
hy the application code. 



The Application Menu 

The user interfaces with the applications handler of the 
HP 4953 A in the same way as with any other function of 
the instrument: through a menu. The Application menu 
looks like Fig. 9 + There is a catalog of the applications that 
are loaded, showing the name, size, and description of 
en h, The user can scroll through the catalog using the 
cursor keys. At the bottom of the screen are memory use 
statistics, showing the total size of the applications loaded, 
the available space, the data buffer size, the largest block 
of contiguous space available, and the number of blocks 
of data present in the data buffer. 

Soft keys available in the Application menu depend on 
the application selected by the cursor in the application 
catalog display, The Load application. Buffer size, and Exit keys 
are always present. If the selected application is storable. 
a Store application key appears- If the application can be de- 
leted, a Delete application kev appears If the application Is 
executable, an Execute application key appears. In line with 
the general philosophy of the instrument, invalid choices 
are not presented to the use J 

The mass storage and remote facilities of the HP 4 ( J53A 
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are used for applications storage and transfer. Applications 
may be stored and loaded from tape and uploaded or down- 
loaded to or from a remote unit. A simple security scheme 
is implemented on tape or remote transfers. An application 
may be storable. nonstorable, or a master application. A 
master application can be copied, but its copies cannot be 
copied. Most application programs sold for the HP 495 3 A 
sme masters. This security scheme is maintained I <\ the tape 
editing program that comes with each HP 4953 A. 

Memory to store applications is traded off wilh memory 
for the data capture buffer. In an HP 4953A with Option 
01 (expanded memory) there is a total of 448K bytes to be 
divided, The data capture buffer must be a minimum of 
1BK bytes, leaving 4A2W bytes for applications. If the 
maximum data capture buffer size oi 256K bytes is needed, 
192K bytes is left over for applications. 

Performance 

Performance in a protocol analyzer is a function of sev- 
eral factors. First, there is front-end speed, or how fast the 
machine can receive and transmit data from tin- data com- 
munications line under test. The f H 1 4953 A can communi- 
cate at data rates up to 72,000 bits per second full-duplex 
and up to 256,000 bits per second in a monitor-only mode 
with external clocking for bit-oriented protocols (BOPs). 
The critical section for front-end speed is the data link 
controller (DLC, see article, page 18). The DLC is responsible 
for converting the bit stream on the data communications 
line into the characters for character-oriented protocols 
(CGFs] or into the frames associated with BOPs, Obviously, 
the front end must keep up with the bit rate of the data 
communications line under test, or all is lost. For the DLC 
to simulate ur emulate, it must he ftMe to drive the data 
communications line at speed. It is also desirable to be 
able to maintain the data rate lor an indefinite period of 
lime, The ability of the machine lu drive a data communi- 
cations line without pausing between chunks of data is 
known as utilization. In the HP 4953A there is Q relatively 
constant time between the end of one chunk of data and 
the beginning of the next. This causes the utilization for 
smalt Strings of data (10 characters) to vary from 85 
1200 bps to 99,8% at 72 kbps. For large strings [ 100 chaon 
tersi, utilization varies Uom 99% at 1200 bps to 99.9% at 

:ips. 



Another measure of performance for a protocol analyzer 
is the number of simultaneous triggers that may be active 
at once and the complexity allowed in specifying those 
triggers. The HP 4953 A allows up to 63 trigger characters. 
The 63 characters may be treated as 63 separate triggers, 
each of which specifies a different action when found, or 
may be combined to form larger complex trigger strings up 
to 63 characters in length. For each character in a trigger, 
the HP 4953 has the ability to test against the complement 
(NOT] of that character or mask out bits of the character. 
The HI 3 495;i A can also trigger on special characters such 
as start and end flags, frame check sequences [FCS). and 
framing or parity errors. 

Two decisions made early in the HP 4953A development 
were that it would run as close to real time as possible and 
that It would not allow any data to be lost. This had a very 
definite effe< t on ihe architecture of both the hardware and 
1 he run-time software Often protoi 1 A analyzers collect data 
from the data communications line and put it into a large 
memory buffer where they can analyze the data at their 
own speed. This is called postana lysis, and it has one side 
effect: it allows the point of analysis to fall behind what 
is happening on the line. To force the HP 4953 A to keep 
up with real time, the point erf analysis has been moved 
out of the data buffer into the data stream between the DLC 
and the data buffet. 

It is important that the protocol analyzer quickly respond 
to a trigger event, perform the actions required as a result 
of finding the trigger- get set up for the next trig^r, and 
Klart analysis again. A small I IKO f first in, firs! out) buffer 
is inserted at the output of the DLC to allow the analyzer 
time to set up and get running again after it has stopped 
as a result of having found a trigger. This brings the differ- 
ence between real time and the point oi analysis in ihe HP 
495 3 A to at most the size of the FIFO plus a character or 
two of buffering in the DLC Staying close to real lime gives 
the IIP 4953A the ability to respond to events mi the data 
communications line very quickly* 
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Simple Architecture Provides High 
Performance for Protocol Analysis 



by Stephen H. Witt and Roger W. Ruhnow 



THEHP4953A is a general-purpose high-performance 
protocol analyzer thai is capable of monitoring serial 
data streams at 256 kbps and simulating serial data 
streams at 72 kbps, The HP 4953 A is also capable of recog- 
nizing data patterns in the data stream and responding to 
these patterns with a variety of menu functions, A primary 
design consideration for the HP 4953A was to perform as 
a real-time monitor. This means the analyzer must process, 
display, and store measurement data without falling behind 
the activity occurring on the network under test. A second 
concern was cost. The instrument is intended for general- 
purpose use and must be affordable, A third considers I inn 
was size and weight. The analyzer must be portable. There- 
fore, a simple system architecture was chosen, one that 
would be inexpensive and portable, and would perform 
wall* 

The protocol analyzer interfaces to the line under test 
via an interface pod. The pod provides the physical and 
electrical connections between the Data Terminal Equip- 
ment (DTE) or the Data Circuit-Terminating Equipment 
(DCE) and the HP 4953A Protocol Analyzer [see Fig, 1). 

There are six major blocks In the system, as shown in 
the block diagram t Fig, 2; 

■ System processor 

■ System memory 

■ System input/output 

■ Trap machine 

■ Front-end processor 

■ Power supply. 

The system processor, system memory, and I/O as- 
semblies make up a special-purpose computer that inter- 
faces to the front-end processor and the trap machine, The 
front-end processor provides the necessary control of the 
interface to the network under test. The trap machine pro- 
vides data analysis [triggering capability) of the data being 
acquired. 



V 

I Y Cable 



HP 4953A 
Protocol 

Analyzer 



Fig. 1 . The protocol analyzer interfaces to the line under test 

by means of an interface pod. 



System Processor 

The system processor provides processing and control 
for theHP4953A, All other blocks in the system communi- 
cate with the system processor via memory mapped I/O 
I see system processor address map, Fig, 3), The system 
processor consists of an 8-MHz 68000 processor [CPU]. 
program memory, address decoding, timers, DMA control, 
and interrupt control. Most of the system bus interface 
si 'j rials originate on the system processor. Board enable 
signals (to communicate with the other blocks via memory 
mapped I/O], the system reset signal, the system clock (16 
MHz], the bus error signal, and the data transfer handshak- 
ing signals are generated by the system processor. 

System Memory 

The system memory consists of the ROM array (384K 
bytes) and the RAM array (standard 128k bytes or optional 
51 2K bytes). Both the ROM ami the RAM are 16 bits wide. 
This is system memory that is directly addressable by the 
68000 and is not accessible to any other processor. The 
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Fig. 2. HP 4953 A Protocol Analyzer block diagram. 
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ROM array contains all the system software. 

The RAM array is segmented as follows: 

■ System RAM: 64 K ! 

■ Dfita capture buffer: 16K to 256K bytes 

■ Application program space: to 432K bytes 

The system RAM is fixed in size. The data capture buffer 
and the application program space sizes are designated by 
the user through software control. More details of the op- 
eration of the data capture buffer and the application pro- 
gram space can be found in the articles on pages 18 and 4, 
respe 

System I 

Alt user interaction with the HP 4953A is accomplished 
via the system 10, which consists of the keyboard and 
keyboard interlace, the CRT display, the RS-232-C inter- 
face, and the system mass storage tape subsystem . It is only 
through these I/O interfaces that the user can alter the con- 
figuration of the system. 

The keyboard is used to control the operation of the 
instrument through menu entry and interaction with data. 
The keyboard I/O section includes a full ASCII keyboard 
with eight soft keys mounted to the front of the instrument 
with hinges that allow for pivotal movement. It interfaces 
to the system processor through the keyboard interface cir- 
cuitry, which interrupts the processor when a key is 
pressed. The system processor then reads the keyboard reg- 
ister to determine which key was pressed. 

The RS-232-C interface exists for two purposes: to access 
a printer and to provide remote control. The system proces- 
sor communicates with the RS-232-C interface through 
memory mapped I/O registers. Back -pan el switches are 



Standard System RAM 
128K Bytes 

Extended System RAM (Optional) 
51 2K Bytes 



System ROM (System Program Memory) 
3S4K Bytes 



Trap Machine Registers 



Data Link Control Registers 



Tape Controller Registers 



Keyboard Register 



RS-232-C (ACIA) Registers 



Back- Panel Registers 



CRT Controller Registers 



Display RAM 
8K Bytes 



System Processor DMA Control 
Registers 



System Processor Timer Registers 



System Processor DMA Page Latch 



Performance Verification Display 
Register 



Beeper, Performance Verification 

Switches, and Memory Size Jumper 

Registers 



Fig. 3, HP 4953 A system address map. The 68000 system 
processor communicates with the other blocks in the system 
via memory mapped ttO. 



used to set the address of slave units in a con trailer slave 
remote control environ meat. They are also used to select 
a baud rate to which the instrument defaults at power-on. 
After power-on. the baud rate may be changed via sol 
selection. 

The tape section of the I/O subsystem is made up of the 
tape controller, the tape preamplifier, and the DC 100 tape 
transport. The tape system piovidt I a user's 

menus, buffer data, rim data, or application programs. Data 
is transferred from the tape to the system processor or vice 
versa using direct memory access (DMA)* The 68000 deals 
in logical blocks of data referred to as records. It sends the 
tape subsystem commands to control these blocks of data. 

The tape controller is made up of a system bus interface 
to the system processor, an 8039 processor, a state machine* 
a servo control loop, and the tape preamplifier. The tape 
preamplifier buffers Hie low-voltage signals between the 
tape transport and the tape controller. The DClOO taps 
transport assembly consists of the motor assembly, the read 
and write heads, the hole detection mechanism, the 
hardware for holding the tape cartridge, and the hardware 
for ejecting the tape cartridge, 

The display is made up of the digital controller as- 
semblies, the primary display driver (high- voltage board), 
the secondary display driver (sweep board), and the 9-inch 
CRT display tute 

The CRT controller assemblies provide all of the digital 
mapping from the display memory in the system processor 
address space to the analog circuitry that controls the elec- 
tron beam for energizing the CRT tube. The display memory 
is accessed by the system processor in a normal 68000 
write mode via memory mapped I/O. 

The display uses a raster-scan system and is character 
based. The screen can hold 25 lines of 80 characters each 
for a total of 2000 characters per display. The CRT control- 
ler can implement both normal and large (2 x in each di- 
mension) characters. The normal size characters use 7xy 
dots in a 9xl5-dot character cell, Large characters use 
14x18 dots in in 18 * :KI-dot cell. 

Four character sets are available for the display: ASCII, 
EBCDIC, hexadecimal, and specials. The special character 
set provides datacom characters (e.g., start flags, slop flags, 
In i me check sequences) and line drawing character (for 
timing diagrams and display borders). The user may define 
a character code set that uses the ASCII character set for 
i printable characters. The system processor performs the 
chiinicter-set mapping function from a table loaded from 
tape or keyboard. 1 "his mapping function is transparent to 
the CRT assembly. If no printable character exists for a 
code, the hexadecimal character is displayed. 

Character attributes include half bright, underline, in- 
verse video, cursor (alternates between inverse video and 
normal video at 4 Hz), overline, and blinking (the cell is 
blanked at 2 Hz). 

Front-End Processor 

The Front-end processor is made up of the data link inter- 
face, the data link control, the LED display, and the inter- 
fa err pod, These assemblies interface to the system proces- 
sor as une entity through Ihe data link control, The data 
link control (DLC] provides the intelligence required to 

m.' Mir ii if.'-j on page 15) 
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Protocol Analyzer Power Supply Design 



The internal power requirements of the HP 4953A are -+ 5V al 
10A, + 12Vat4A, -5V at 0.1 A, and - 12V at 0.1 A The + 12V 
output runs the display, the tape drive, and the fan These sub- 

systems place certain constraints on the supply For Instance, 
the display is sensitive to small voltage variations, while the tape 
motor and the fan have large current surges. The power supply 
also had to pass VDE level B for EMI and the design time needed 
to be short 

Given the above constraints, a switching type supply was de- 
signed with linear regulators on the -12V, -12V, and -5V 
outputs. Three-pm regulators are used on the -5V and -12V 
outputs A remote-sensed regulator is used on the 4- 12V output 
instead of isolating the display supply with a separate regulator. 
This minimizes the number of outputs That need protection. A 
low-dropout (IV) regulator is used to increase efficiency. 

The switching circuit (Fig. 1 ) is a forward converter operating 
at 50 kHz. A forward converter transfers power to the output 
when the switching transistor is on A transistor and FET combi- 
nation is used for the switch: a low-voltage FET switches a high- 
voltage bipolar transistor in the common-base configuration This 
yields lower cost and is more rugged that a single bipolar tran- 
sistor or FET 

The main switching transistor rs protected by a comparator 
that senses the instantaneous current in the transformer primary. 
If the current exceeds a preset value, the switching pulse is 
turned off eariy. This limits the current during an overload condi- 



tion. If the overload is sustained for more than 50 ms, the supply 
turns off and remains off. The ac power must be turned off for 
at least five seconds to resume normal operations when power 
is reapplied The supply will also shut down if any output is 10% 
over its specified voltage for mare than 10>s, The + 12V f - 12V, 
and -5V regulators have individual current limrters. However, 
power dissipation in the regulators is large when they are current 
limiting. To prevent damage, the supply shuts down if any of 
these outputs is 10% under specified voltage for 50 ms. These 
time delays ensure that turn-on and load surges will not trip the 
protection circuitry, The protection circuitry is fabricated on a 
trvck-film hybrid to reduce cost and save board area. 

Normally m a power supply of this type, f Iter networks called 
snubbers are used on all of the transformer windings to reduce 
voltage transients that could damage the semiconductors. These 
networks are eliminated by us>ng bifilar wsndings on the trans- 
former's primary and flyback windings, and by using the most 
recent technology available for the rectifiers 

Stephen M. Ernst 

Development Engineer 
Colorado Telecommunications Division 
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*+12V 



Fig, 1 , Schematic dwgratn of the 
HP 4953A power supply 
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(contim, 

acquire data, translate data, provide timing, provide data, 
and perform ail other tasks necessary to interface with a 
user's network. The data link control is made up of two 
microprocessors operating in parallel: a Z80 and a Z8. The 
Z80 has 32K bytes of EPROM program memory and 16K 
bytes of RAM storage. It executes the protocol code. The 
Z8 has 2K bvtes of ROM and 256 bytes of RAM. both inter- 
nal to the part, The Z8 bandies the interface lead status 
and the timing functions, and puts the data in the capture 
buffer The Z8 is called the timing processor. Details of the 
front-end design are in the article on page 18. 

Trap Machine 

The trap machine scans the DLC data from the HP 495 3 A 
front end for user-programmed character sequences, lead 
status changes, and errors or specials (conditions not 
specified by other data types} in data link protocol. The 
trap machine interfaces to the system bus and controls DMA 
transfers from the data link control to the system memory. 
Data patterns are scanned as they "pass by" on the system 
bus. On fin ding a trigger sequence, the trap machine reports 
trigger information to the system processor. 

The trap machine has a mask field and an instruction 



field associated with each trigger character, The mask field 
allows "don't care" conditions to be specified on a bit-by- 
bit basis. The instruction field is used to specify trigger 
type and NOT conditions in addition to containing some 
reserved fields for system use. There are 64 available trig- 
gers* one of which is reserved for system use. 

The trap machine keeps track of the time information 
and the interface lead status information put into the data 
capture buffer so that the condition of the interface can be 
reported to the system processor when a trigger is reported. 

The trap machine consists of a C2000 gate array* a few 
TTL integrated circuits for svstera interfacing, and three 
NMOS RAMs. 

In this description, several references are made to DLC 
data types. These formats are the same as for buffer memory 
and are described in the article on page 18. 

Trigger Definition 

A trigger is a sequence of characters or elements that the 
user wants to match in data received from the DLC A user 
defines triggers in the Monitor and Simulate menus to di- 
rect run-time execution. Each element of a trigger consists 
of three bytes: a character byte, a mask byte, and an instruo 



Protocol Analyzer Mechanical Design 



The HP 4953A Protocol Analyser uses standard HP cabinetry, 
but is the first 7-ineh-high. full-width cabinet in a 10.6-inch depth 
used in the corporation This nonstandard depth was chosen 
because the HP 4953 A is frequently used as a field service 
instrument. As a result, low weight and a size capable of filling 
under an airplane seat were important constraints 

The nine 6 x 9-inch digital boards load from (he top of the HP 
4953A into a bottom -mounted backplane and run parallel to the 
front of the instrument, For serviceability, the boards can sit atop 
an extender card and Face [he front for easy access l< \ 
side of (he hoard The two-piece connectors are staggered 
across the backplane so that it is physically impossible to mate 
a digital board into the wrong slot The two CRT driver boards, 
which, with top and bottom covers removed, hinge out of the 
instrument for easy servicing, and the display tube consume 
nearly all of the remaining volume inside the box. This leaves 
insufficienl room for the power supply Consequently, the power 
supply mounts vertically inside the rear panel, which protrudes 
out the back of the instrument The standard rear feet were there- 
fore too short to allow operation of the instrument while standing 
on its rear feer with the necessary interface cabling connected 
to the rear panel Consequently, a rear foot was tooled that is 
one inch longer than standa rd to provide the necessary additional 
ground clearance. 

With no room on the rear panel for the necessary cooling fan. 
the fan was mounted on rhe side It draws ambient air through 
the right side cover across The digital boards and power supply, 
and exhausts it out the left side. 

On the front of the instrument is a full, nondeiachabJe, fold- 
down keyboard lockable at any desired angle. The front panel 
has a 9-inch monochrome CRT, a line switch, a DC100 tape 
transport, and a bank of 44 LEDs The LEDs, 22 red and 22 
green, indicate the status (on and off or mark and space) of the 
interface fines of the system under test Because there exist 
several Interface standards throughout the world, each with dif- 



fering numbers of lines and differing nomenclature associated 
wiih each fine, a simple means of changing the number and 
names of these lines' status indicators was needed. An overlay 
card that snaps into the front panel over ihe LEDs was designed 
tor each interface, Only the correct number of LEDs can be seen 
through each overlay, each with its proper nomenclature 

The hinge mechanism on the fold-down keyboard extended 
below the plane of a standard HP bottom foot, which snap-mounts 
onto Ihe bottom cover. Other feet used throughout the company 
were inappropriately talf tor use on the bottom of the instrument. 
As a result, a new bottom foot, which uses a fold-down tilt stand 
similar to the one used with the standard bottom foot, was tooted. 
This new foor mounts to the front frame instead of the bottom 
cover 

The HP 4953A's handle is a formed, rigid meta) strap with a 
molded hand grip It mounts to the sides of the front frame A 
side strap recessed into the side panel (typical on many HP 
instruments) was rejected for two reasons first, it cut down the 
available path for airflow through the cabinet by nearly 50%, and 
second, the form factor for carrying the instrument in this orien- 
tation made it awkward and uncomfortable 

The field service environment in which the HP 4953A is fre- 
quently used demands that it be especially rugged. The instru- 
ment was tested to HPs new class B-1 standards for shock and 
vibration No failures were found during eiiher resonant vibration 
dwelling, or during random vibration testing. In shock tests, the 
instrument withstood at least 56g before experiencing unaccept- 
able damage. Even at these shock levels, ihe damage was to 
the outer structure and did not affect Ihe proper operation of the 
instrument. 



Ken Krebs 

Development Engineer 

Colorado Telecommunications Division 
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lion byte. The mask byte contains the bit pattern the user 
wishes to AND with the received DLC character before com- 
paring it to the character byte. An example of masking 
would be the elimination of the ASCII parity bit. The 
character byte contains the byte the user wants to use as a 
trigger element. The instruction byte contains the trigger 
type, comparison criteria, and flags indicating if this ele- 
ment is the start of a trigger, the end of a trigger, and /or 
the last trigger element to be considered before obtaining 
a new DLC data character. The comparison criteria possible 
are equal and not equal. 

The three NMOS RAMs hold the trigger triplets. Sixty- 
four triplets are available, G3 for the user ;\nd one for the 
system. These can be partitioned into a number of triggers, 
each having a variable number of elements. If all of the 
user's elements are used, there can be from one trigger of 
63 elements to 63 triggers of one element each. Triggers 
are entered into RAM from the lower addresses through 
the higher addresses. The trigger byte is entered into the 
character RAM, the mask byte is entered into the mask 
RAM, and the trigger type, comparison criteria, and trigger 
flags are entered into the instruction RAM. If the triplet is 
the first in a trigger, the start flag is set in the Instruction 
RAM, If the triplet is the last in a trigger, the end flag is 
set in the instruction RAM. If the triplet is the last defined 
in RAM, the last flag is set in the instruction RAM. A trigger 
can be defined but rendered inactive by not setting its start 
flag, These RAMs are read from and written to by the system 
processor and are accessed by the gate array while the trap 
machine is running. 

Search Algorithm 

When searching For a programmed trigger, the trap 
machine uses the concept of a link bit to indicate the pro- 
gression of a trigger sequence. A link bit is one bit of infor- 
mation associated with each trigger element, By definition, 
ij link hit associates! with a bigger pieman! is b»1 it and 
only if a sequence has been found in the DLC data that 
matches the trigger sequence through that trigger element. 
For example, if a trigger consists of trigger elements DTE 
A. DTE L P and DTE M T and the data received from the DLC 
is DTE A and DTE L. the link bit associated with the trigger 
element DTE L would be set, As the trap machine continues 
to receive DLC data that matches the trigger sequence, the 
link bit will move (or propagate] from trigger element to 
trigger element until it propagates to an element with the 
end flag set. In this case the trigger has been satisified, 

There are several restrictions on the propagation of a link 
bit. If the type of the received DLC character is not the 
same as the trigger type, the link bits for that trigger nre 
not modified, This property allows a trigger sequence to 
be unaffected by DLC data types other than its own. If the 
trigger type is the same as the received DLC character then 
the propagation of the link bit is controlled by additional 
considerations. 

The mask byte is ANDed with the DLC character and the 
result is compared with the character byte. This result must 
match the comparison criteria specified in the trigger ele- 
ment's instruction byte, Lf these criteria are not met the 
link bit is set to zero, terminating the propagation of any 
link bit by that element, This occurs when the DLC data 



sequence fails to match the trigger sequence through that 
element. If the comparison criteria are met. the link bit will 
be set if and only if the link bit of the previous trigger 
element was set before its last evaluation, or this element 
is the start of a trigger (it* start flag is set). 

As an example of the above rules, consider Table I. The 
top row is a programmed trigger sequence consisting of the 
DCE ASCII characters A, B t A, B, C, and A in that order. The 
leftmost column shows the data sequence received from 
the DLC t consisting of the DCE ASCII characters A, B T A, 
and B, DTE ASCII character C, and DCE ASCII characters 
C and A, in that order. Since the DTE character is not the 
same type as the trigger elements, it is ignored and is essen- 
tially removed from the DLC data sequence. If this is done 
the DLC data sequence appears identical to the trigger se- 
quence, so a trigger is present. The table is the set of link 
bits associated with the trigger elements. The column of 
ones and zeros under a trigger element shows the link bit 
for that element. The link bits are initialized to zero before 
the searching algorithm begins, as seen in the first row. 
While a DLC character is being compared to the trigger 
sequence(s). the link bits are changed to the values shown 
in the corresponding raw of the DLC data word. When the 
link bit becomes set for the last element in the trigger se- 
quence, a trigger has been found, 

As mentioned, the link bits must first be set to zero to 
prevent false triggers, since they represent propagating trig- 
ger sequences. The first DLC data word is DCE A. This word 
is compared to all of the trigger elements in order from left 
to right. The first element is DCE A. Using the conditions 
for link bit propagation, it is easy to see that only the link 
bit associated with DCE A will become set. 

The second DLC character is DCE B. As this word is 
sequentially compared to the elements in the trigger, it can 
be seen that only the first trigger element DCE B satisfies 
all conditions, so its link bit is set- The third received DLC 
data word is DCE A. As this word is sequentially compared 
to the elements in the trigger, two link bits are set, The 
second link bit becomes set because the trap machine rec- 
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Making a Protocol Analyzer Producible and Serviceable 



Producifritty and serviceability are important issues 
product destgn To achieve both gc i mportanl to have 

effective performan: on software, whtch indicates 

wtietber the instrument is functional and enough additional 
hardware and software to a flow any failures in the instrument to 
be local ec s also important that the additions to the 

instrument needed strictly for performance verification and trou- 
bleshooting be kept to a minimum to keep production cost as 
low as possible For example, to service the HP 4953A hardware, 
no electronic tools or extender cables are needed All of the 
boards are readily accessible and each has been designed to 
be easily repaired 

Test points to be used for signature analysis (SA) troubleshoot- 
ing are located at the top of each board to provide for easy 
hookup of the signature analyzer probe when the boards are in 
the cardcage The test points consist of two rows of X M-post-type 
connectors (where X is the number of test points), rather than 
the conventional single test points Using the connectors. SA 
probes can be attached quickly without using the cups supplied 
with the SA probe. The double row of test points allows more 
than one connection to be made to each test node, (n addition, 
using connectors for test points alfows all of the test pomis to 
be loaded at one time, thus reducing production cost 

M-post-type connectors are also used to implement the many 
jumpers required to break feedback loops for SA troubleshooting. 
Using the connectors instead of the more common DfP jumpers 
conserves board space and makes it much clearer which jumper 
position is normal and which position is for troubleshooting. 

Over seventy performance verification and troubleshooting 
tests were written for the HP 4953 A. The same code is used for 
performance verification and signature analysis as much as pos- 
sible. This reduces the amount of code needed and avoids the 



Tat sometimes anses when performance ver ? 
detects a problem in a circuit but separate SA soft ware stimu- 
lates trie circuit m a efferent manner, so the failure cannot be 
locateo 

lajonty of the tests are executed each time the instrument 
is powered-on and take less than eight secor ptete 

Tests that require user interaction, such as the tape test, are 
accessible through a top- level soft' 

The tests are numbered in the order they are executed. Since 
testing begins at the heart of the instrument and works outwards. 
troubleshooting begins with the failing test having the lowest test 
number Any test can be individually cycled for SA troubleshoot- 
ing or for finding intermittent failures by setting a switch located 
on the CPU board to the desired test number and pressing the 
reset button Switch settings are also available for cycltng particu- 
lar groups of tests or for cycling all of the tests and outputting 
the results to a printer. 

Most test failures are displayed on the CRT. However before 
the CRT can be used to display failure information, there must 
be some confidence that the CRT circuitry itself is functional 
Therefore. I he power-on tests are divided into two sets, the first 
dedicated to testing the circuitry needed to access the CRT 
display. If any of the tests in the first set fails, th^ failure is indicated 
by repetitively displaying the test number of the failing test on a 
seven-segment display located on the CPU board Most of the 
remainder of the HP 4953A is tested by the second set of power- 
on tests Any failures in this set of tests are displayed on the CRT 

John ft. Rader 

Development Engineer 
Colorado Telecommunications Division 



agnizes that another trigger sequin c is burnt* received with 
this character as the first element. This property is desirable 
in the detection of overlapping triggers, Many link biis in 
a trigger can be set at any given time- 

An interesting item is the reception of the DTE C charac- 
ter from the DLC, The link bits should not be changed with 
the reception of this character so the trap machine simply 
copies the link bits, as indicated in the table, The trigger 
is finally found when the link bit in the last DCE A trigger 
element becomes set. 

It is possible to be searching for more than one trigger 
at a time. This is accomplished by sefjiiHiiiially i irnipariiig 
the DLC character to all triggers before requesting another 
DLC character. When considering multiple triggers, link 
bits from one trigger do not affect another trigger. Table II 
shows an example of two triggers- 
Data FEow Description 

Data is provided to and acquired from the network under 
test by the interface pod, The network data consists of serial 
data, clocks, and interface control leads, The interface pod 
recognizes voltage levels and changes on the interface .mil 
converts these voltages into TTL levels that can he inter- 
preted by the digital hardware in the Hi 1 4U53A. The inter- 
face pod interfaces to the data link interface (DLI). The DLI 
interprets I he data, clocks, and leads and displays this in- 
formation by writing tu the LED assembly on the front 



panel. 

The DLI detects interface lead status changes and passes 
this information along with the data and clocks from the 
interface pod to the data link control (DLC}. The DLC r (in- 
verts the serial data into an 8-bit paraliel formal* keeps 
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Propagation of link bits through two triggers 
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1 1 a* k of 18 bits of relative time, and maintains Hm status 
of 15 interface control lends Time stamps and informatinn 
identifying the data type (see "Data Caplore Buffer, page 
22) are added to the 8-bit data byte, forming a 1 6 -hit word. 
The DLC recognizes specific protocol events on the network 
under test and identifies those by generating "specials" ior 
insertion in the buffer. The 16-bit words are passed from 
the DLC to the system memory via a 16-bit DMA channel 
that is maintained by the system processor. 

The trap machine controls the Now of data from the DLC 
to the system memory by acknowledging the DLC's DMA 
requests lo the system processor. 1'he trap machine reads 
the data during each DMA cycle as it is transferred to the 
system memory. The trap machine is programmed to detect 
user-entered trigger sequences. When a trigger sequence is 
detected, the trap machine interrupts the system processor 
and reports the trigger. The system processor halts the tnm 
machine, executes the appropriate menu functions, and 
then restarts the trap machine. During this interval the trap 
machine is halted and no data is transferred to the system 
memory. The data passes through a 128-byte-deep FIFO 
(first tn, first out) buffer on the DLC, This FIFO allows for 
pauses in the data flow to the system memory. 

The data is now stored in I he data capture buffer in the 
system memory. The system processor maintains a second 
16-bit DMA channel between the system memory and the 
tape controller. While menu programs are executing, they 
can control the flow of data to the tape. Run -time data may 
thus be stored lo tape. 

The system processor has access to the system memory 
and can read data from the data capture buffer for display 



on the CRT. The display RAM on the CRT is accessed 
through tlm system processor's address space. The system 
processor manipulates the data to provide [or various dis- 
play formats ami sei'iurm es. 

For simulation , the system processor creates data strings 
in parallel formal and interface control lead settings from 
information entered by t he user. This information is passed 
to the DLC where the data is converted from parallel to 
serial format for transmission on the network. Clocks are 
supplied and leads are set accordingly. The DLC calculates 
the necessary error checking sequences and appends these 
to the data. The DL1 turns the LEDs on and off according 
to the information sent. The interface pod delects the data, 
clocks, and leads set by the instrument and reports this 
information via the data path discussed above for monitor- 
ing data. 
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Serial Data Acquisition and Simulation for 
a High-Speed Protocol Analyzer 

by Mark D. Keisling, Dorothy J. Yackle, David B. Karlin, and Elizabeth Gates Moore 



THE FRONT END of the HP 435 3 A Protocol Analyzer 
is a dedicated subsystem that provides the serial test 
interface for the 66000 system processor. The front 
end consists of four assemblies (see Fig. 1): the pod [there 
are several to choose from), the data link interface (DLI). 
the data link control (DLCJ> and the lead status display 
(LEDs), The pod, located outside the instrument, is con- 
nected to the rear panel of the HP 495 3 A using a two-meter 
50-condnctor cable. The other three assemblies (DLI, DLC, 
LEDs) are inside the mainframe. 

Fig. 2 is a detailed block diagram of the front end. Two 
microprocessors in the DLC control all the functions of the 
front end. It is the DLC that communicates with the 68CKJ0 
system processor, The DLI assembly functions as an inter- 
face between the external pod. the DLC, and the lead status 



display. The pod connects to the network or device being 
le.sled. The lead status display indicates the logic levels of 
all the interface leads on the pod, 

The front end monitors the data and control leads of the 
device under test. This information is passed from the de- 
vice through the pod to the DLL The DLI routes the data 
to the proper channel of a serial input/output device (SIO) 
located on the DLC. Working with the front-end firmware, 
the SIO does some initial analysis of the incoming data 
and then passes the data and analysis information to fjbs 
timing processor (a ZS MCU), The timing processor formats 
the data into the buffer data formal [see "Data Capture 
Buffer," page 22) and appends timing information to the' 
data. The resulting 16-bit word goes to a 128-word first in, 
first out [FIFO) memory device, and then to the system 
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Fig. 1 , HP 4953 A Protocol Analyzer simplified front-end block 

diagram 

buffer memory via a 16-bit direct memory access [DMA) 
channel. The lead information is retained by the DLL Only 
changes in lead status are reported to the DLQ 

The timing processor also maintains a 16-bit status word 
of the lead states. This status word is sent to the FIFO 
following the lead change word, The status word is also 
written to the FIFO following a lickmark word. Tickmarks 
are generated periodically by the timing processor to main- 
tain timing integrity during the execution of a run. The 
information sent to the FIFO is eventually sent to the system 
buffer memory. Lead status information is also latched into 
peripheral driver devices that drive the LEDs of I he lead 
status display assembly. 

The front end can also send data out of the pod to the 
device under test and can drive the control leads, These 
si nm hit ion capabilities are activated in response to Send 
Data String and Set Lead commands received from the 6800U 
system, A data byte accompanying the command specifies 



which string is to be sent or which lead is to be set to what 
state, The strings are downloaded from the system to the 
DLC before the run begins. Upon receiving a Send Data Stnng 
command, the DLC fetches the string from its- memory and 
passes the string data byte -by -byte to the SIO. The serial 
data travels out of the SIO through the DLI to the selected 
data lead on the pod and on to the device under test. Inter- 
face clocks are generated oo the DLJ and sent to the 
and to the SIO. Upon receiving a Set Lead command, the 
DLC passes the byte containing the control lead information 
through the DLI directly to the pod, where the chosen lead 
is set on or off. 

The Pod 

The pod translates the physical interface signals (e.g., 
RS-232-C, R5-449) from the interface voltage levels to TTL 
levels and from TTL levels to the interface voltage le 
[see Fig, 3), Up to fifteen interface control leads, four data 
leads, and three clock leads can be monitored and driven. 
Each control, data, or clock lead can take on a voltage level 
within one of three ranges; logic 1 [V< - V r ), logic (V > 
+ VJ , or inactive ( — V r < V < -f V r ). V r is a reference voltage 
[3 volts for the RS~232~C pod). These TTL signal levels are 
transferred to the DLI using a multiplexing scheme. \ 
lead (up to 22] is assigned an address. The control leads 
occupy addresses through 14. The data and clock leads 
occupy addresses lfi through 22. Address 15 is not used. 
As each lead is addressed, the pod responds by indicating 
which of the three voltage ranges the lead is in. The front- 
end hardware within the instrument can only determine 
the state of the control leads using this addressing scheme. 

The pod can also drive any of the leads (see Fig, 4). Each 
of the drivers can be disabled so that I he lead looks like a 
high-impedance load. When enabled, each driver can drive 
its lead to the voltage level representing a logic 1 or 0. The 
pod is given a seven-bit command. The lower five hits 
indicate which lead is to be modified (using the same ad- 
dressing scheme as above), and the upper tw r o bits indicate 
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Fig, 3, Pod receiver functions. 

whether or not the driver for that lead is to be active and, 
if active, what the logic level of the lead is tn he (the legit; 
level Indication is not used for the data and clock leads). 
The pod is also supplied wilh a serial data signal and a 
serial clock signal, 

All drivers are disabled when the instrument is powered 
on and whenever the RESET key on the keyboard is pressed. 
The proper drivers are enabled before the run begins. The 
Stop State menu determines which drivers are left enabled 
at the termination of a run. 

Data Link Interface 

The signals from the 50-conductor pod cable are i .on- 
nected to the data Jink interface using the system mother- 
board. The DL1 assembly consists of five functional blocks: 
pod interface, baud rate generator, signal multiplexing, lead 
change detection, and NRZI encoding/decoding. 

The pod interface block serves to buffer the signals sent 
to and received from the pod. All serial data and clock 
signals are driven differentially for increased noise immu- 
nity. 

The baud rate generator block consists of a primary baud 
rate generator and a secondary baud rate generator. The 
primary generator can be programmed to provide a symmet- 
rical clock of any frequency from 10.0 Hz to 999 kHz. Res- 
olution is three significant digits, and accuracy is 0,005 % t 
which is based on the 12 -MHz front-end clock crystal. The 
secondary generator provides a xl6 clock for asynchro- 
nous data communications. The secondary baud rate 
generator can be programmed to provide any of the follow- 
ing baud rates in bits per second: 50, 75, 110 t 134.5, 150, 
300, 600, 1200, 1800, 2000, 2400, 3600. 4800, 7200, 9600 T 
or 19200, 

The signal multiplexing block of the DLI provides a 
means of routing the serial data and clock signals from the 
pod to the appropriate channel of the serial input/output 
device on the DLC assembly. The multiplexing block also 
can route these signals through the NRZI encoding/decod- 
ing block, [NRZI stands for nonreturn to zero inverted; it 
is a serial data encoding scheme that embeds the clock 
signal in the serial data stream.) 

The control lead change detection block keeps track of 
the current states of the fifteen control leads. Should the 
state of any of the control leads change, the front-end pro- 
cessor (located on the DLC) is interrupted. The interrupt 
is provided through channel of the counter-timer circuit 
located on the DLC. Changes on any of the fifteen control 
leads can be ignored by clearing bits in two eight-bit regis- 
ters, 



Data Link Control 

The DLC assembly contains the front-end processor (a 
Z80B CPU), 32K bytes of firmware, 16K bytes of static RAM 
storage, and the timing processor [a Z8 MCU). The DLC 
communicates with the 68000 system processor via an 
eight-bit bidirectional port, Interrupts are supported in 
either direction. The DLC accepts eight-bit commands and 
data and returns eight-bit status bytes to the 58000 system, 

The firmware controlling the ZH0 GPU can be changed 
by downloading new front-end software into the 16K bytes 
■ I RAM, The front-end jump table can be modified to make 
use of this code. This enables applications written for the 
HP 4953A Protocol Analyzer to customize the front-end 
firmware, 

The DLC controls all of the front-end hardware. Registers 
on the DLI and pod are memory mapped within the ZKtJ 
CPU address space. These registers configure and control 
the various functions of the front end. The Z80 CPU can 
also pass commands and data to the Z8 timing processor. 
The timing processor is responsible for formatting data that 
is destined for the system buffer memory. The timing pro- 
cessor's firmware is contained in a ROM that is part of the 
Ztt MCU. This firmware cannot be changed by applications 
software. 

The serial input /out put device (SIO) is located on the 
DLC. The SIO converts data from parallel to serial and from 
serial to parallel. The SIO supports synchronous hit- 
oriented protocols (e.g, f HDLC, X.25), character-oriented 
protocols (e.g., Bisync). and asynchronous data transfers. 
Data is clocked in and out of the SIO at a rate defined either 
by the baud rate generator located on the DLI or by one or 
more of the interface clocks from the pod. The SIO has two 
full-duplex channels, Channel A supports the DTE side of 
the interface under test and channel supports the DCE 
side. 

Another device located on the DLC is the counter-timer 
circuit or CTC. The CTC provides four independent timer/ 
counter channels, Each channel is connected to an external 
signal. Channel is connected to the control lead change 
interrupt from the DLL Whenever a lead change is recog- 
nized, this signal makes a positive transition. The channel 
counter then decrements from 1 to 0, posting an interrupt 
to the 280 CPLI. Channel 1 is connected to a clock signal 
from the pod, allowing timing measurements to be made 
on that clock, Channels 2 and 3 are connected to a 1-kHz 
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clock signal supplied by the DLL This provides two 1-ms- 
resolution timers for the front end. 

Link-Level Protocol Acquisition 

One of the more interesting tasks performed by the front 
end of the HP 4953A is the disseclion of the link-level 
protocol of the data link under test. This is the lowest level 
where information transfer can occur, and therefore, byte, 
frame, message, content* and dialogue synchronization 
must be achieved here. Usually, higher- level protocols are 
only concerned with content and dialogue. This implies 
that the link-level protocol can be viewed as a bridge joL 
the physical conditions on the link with the higher or log- 
ical levels of the data communications path. 

Two fundamental types of link- level protocol are sup- 
ported by the HP 4953 A: bit -oriented and character- 
oriented. BOPs (bit -oriented protocols) are characterized 
by a common frame structure with byte synchronization 
determined by the unique eight-bit pattern called a flag 
(01111110): 

I Flag i Address i Control I Information FCS I Flag I 

The address, control, and FCS [frame check sequence) 
fields are defined relative to the beginning and ending flags, 
This, along with the flag's uniqueness H yields inherent data 
code independence and data transparency (any possible 
bit pattern can be transmitted at any time). 

COPs (character-oriented protocols) do not share this in- 
herent transparency, instead, they are characterized by 
many control characters and a byte synchronization pat- 
tern, which are all dependent upon the data code set used 
by the data link. Numerous frame or block structures exist, 
depending on the type of control or information to be sent 
on the data link: 

l SYN SYN SOH {Header} STX {Data} ETB or ETX {Checksum}! 
I SYN SYN SOH {Header} ETB BCC BCC I 
I SYN SYN SOH {Text} ETX BCC BCC I 
I SYN SYN DLE STX (Text) DLE ETX BCC BCC 
! SYN SYN EOT I 
I SYN SYN {Address} ENQ I 
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Fig. 5. Functions of the BOP service routines for various types 
of received frames 



SYN = Synchronizing character 

SOH = Start of header 

STX = Start of text 

ETB = Ei. -nission block 

ETX = End of text 

EOT = End of trans mission 

ENQ = Enquiry 

OLE = Data link escape 

BCC = Error detection bits 

In fad, not all blocks have error detection bits (BCC) sent 
with them, and the data code and transparency conditions 
determine whether parity checking is in use. Basically 
characters received on the data link specify the block struc- 
ture for that particular block. 

BOPs: Routine Swapping State Machine 

To acquire bit-oriented frames, many functions must be 
performed by the front end. These are divided between the 
serial input output device ISIO) and the HOP software state 
machine. Byleand frame synchronization, data transparent. y. 
and FCS calculation are all handled by the SICX Flags can 
always be detected because of their unique pattern. 
01111110. To guarantee that this pattern never occurs in 
the data stream , a zero is inserted after any five consecutive 
ones in the data stream. The zero Is deleted in decoding 
the data. The FCS is calculated by the SIO using the CCITT 
cyclic redundancy check (CRG) polynomial x'-' + x^ + .v* 
+ I. The SIO determines the accuracy of the FCS. 

The BOP software mainly interprets the bytes of the 
fry me, and t hen sends the data and special characters to 
the system capture buffer (see Fig* 5). On the receipt pi I hi- 
first data character following a flag, the ADDRESS service 
routine is entered. This routine places a Start Flag special 
character into the buffer, folio wed by Ihe address byt". H 
then schedules ihe CONTROL service routine to be executed 
upon receipt of the next data character. This character, the 
control byte, provides the major decision point in the state 
machine, ft contains information to determine the frame 
ill mlnrnirilton, (S) supervisory, or (U) unnumbered, 
Two sequence numbers in the I-frames> N(S] and N(R) t are 
maintained by the software to provide an autoincrement 
capability during simulation. To help the display software, 
a special character is placed in the capture buffer to indicate 
the start of the information field. Only I-frames contain 
information fields, 

Following the control byte t the DATA service routine exe- 
cutes for all the remaining data characters received before 
(he ending flag is encountered. This routine simply places 
the data character in the capture buffer and reassigns itself. 
The end fhin, signified by a different interrupt vector, sig- 
nals the BOP software to check the accuracy of the received 
FCS. This yields either a good FCS special character or a 
bad FCS special < ha racter placed in the capture buffer. One 
oilier type uf Hnd-uf-franie special character can occur, the 
Abort Frame character. To abort a frame, a sequence of eight 
to thirteen consecutive ones with no inserted ^eros must 
be received, In all cases, the end-oF-irarue character is im- 
mediately followed by an End Flag character written to the 
buffer. Finally, the ADDRESS service routine is scheduled 
i'«r fhe start of the next frame, 
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Fig. 6. COP state machine. 



COPS: Table-Driven State Machine 

The requirements for the COP front-end firmware differ 
somewhat from that for t fie BOP. Although less information 
is passed along to the system capture buffer, each block 
received by the COP software requires quite a bit of process- 
ing. The basic tasks performed by this software are: 

■ Maintain byte synchronization 

i* Seod all valid data and control information to the system 
capture buffer 

■ Detect errors based on parity or CRC and report them to 
the system capture buffer. 

To accomplish these tasks, the front end must be able to 
recognise all block types, independent of data code or trans- 
parency. This must be done on a character-by-character basis 
to determine which of these characters to include in the 
CRC, when to check the CRC result, and when to drop the 
present byte sync and look for new byte synchronization. 

Fig, 6 is a diagram of (he COP stale machine. Each time 
-i new character is received by the front end, the state 
machine is entered through an interrupt service routine 
and a data code conversion takes place through I lie type 
tabic. This conversion determines what type the incoming 
character represents, like SYN, SOH, STX, or OLE. The type 
tab It; need only be as large as the data code that contains 



the most characters, and the table's output, the type T is data 
code independent (see Fig, 7), 

The type is then used as a displacement to index into 
the next slate's jump table. Tins table is pointed to by the 
Next State variable and contains a direct pointer to the appro- 
priate output routine. It is not until these routines are exe- 
cuted thai any action based on the present character takes 
place. Parity check, CRC, and byte synchronization are con- 
trolled here. This includes a 2.6-second timeout, which is 
started when byte sync first occurs and is restarted anytime 
another sync pattern is received- If 2.6 seconds elapses 
before the next sync is received or another resync condition 
occurs, then the present byte sync is dropped to start the 
hunt for new synchronization, 

Other tasks done by these output routines include updat- 
ing of the Next State variable, and the control (on/of f) of a 
hardware parity checking mechanism. In the event of a 
parity error, a separate interrupt service routine is entered 
to handle the received character. This routine may or may 
not enter the COP state machine, depending on the type 
of character received. After completion of the selected out- 
put routine, the front end returns to a quiescent state, wait- 
ing for the next character interrupt to occur. The only spe- 
cial characters placed in the capture buffer are parity error 
and block check error, No start block, end block, or abort 
block characters are used. 

Data Capture Buffer 

Information brought in from the line is formatted by the 
front end and then placed in the data capture buffer, The 
buffer can be accessed by entering the Kxamine [Jala menu 
from the top-level meou of the instrument. Display formats 
are offered that provide the information from the tine in 
an organized manner. Once information is put into the 
buffer it is never physically modified. 

The ioteroal buffer format is the same as that used for 
the HP 4955A and the HP 4951 A Protocol Analyzers, Fig, 
8 shows the buffer data types. All of the information tor 
displaying the data in each of the formats is contained in 
this buffer, Any tape containing buffer data or menus can 
be created on one unit and then transported and used on 
anv other. 
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ASCII 7(Odd) 
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SYN 


16 


32 


3A 





ENQ 


85 


2D 


2D 
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OLE 


10 


TO 


1F 
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SOH 


01 


01 


00 
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STX 


02 


02 


0A 
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ITB 


1F 


1F 
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10 


ETB 


97 


26 


OF 


12 


ETX 


83 


03 


2E 


14 


AH Others 


-- 
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16 


NAK 


15 


3D 


3D 


18 


EOT 


04 


37 


1E 


20 


ACKO 


DO 


70 


20 


22 


ACK1 


31 


B1 


23 


22 


WACK 


38 


GB 


26 


22 


RVt 


DC 


7C 


32 


22 


Framing 
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^-... 24 


IDLE 


7F{FF) 


FF 


3F 


26 



Second Control Character 



Fig. 7. Type table for the Btsync 
protocol 
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The Mixed DTE & DCE display format offers the transmit 
and receive data mixed together. A display formal provid- 
ing separate lines for the transmit and receive data is avail- 
able by pressing the DTE over DCE softkey. If the user wants 
to see only one or the other, there are DTE only and DCE only 
formats also. In the Data & State display (Figs. 9 and 10), 
four control leads with the DTE arid I)( 11 

When one of the bit-oriented protocols such as SDLC. 
HPLL t or X.25 has been selected In the Setup menu, the 
information can be displayed in frame and /or packet for- 
mats. The Two Col Frame display format provides a break- 
down of each frame into address, type of frame, N{S)> N(R) t 
poll final bit, data, and PCS, Tht j pa* kel information, such 
as the Q and D bits, modulo, kn, type of packet. Ps, Pr, M 
bit, and data, is supplied with the Two Col Packet display 
format. The Framed Packet dis pi a \ shows I he decoded frame 
and packet at one time with an extra display line for data. 

A message decode format is provided for DDCMP pro- 
tocol. This format displays the message type, byte count, 
Q and S lids response, sequence, address, header GRC r 
data, and data GEC, Each message Is provided with an extra 
display line so that as much data as possible can be shown, 
Applications provide additional display formats for pro- 
tocols added to the HP 4 95 3 A. 

When a page of information is displayed t the address for 
the first character is determined, and then a pointer Is moved 
through the buffer to evaluate the words in the buffer. Only 
some of the information in the buffer is displayable. 

The physical buffer area is broken into 1024-word blocks. 
The block number containing the firs I character on the 
display is shown in the lower right corner of the data dis- 
play. Along with the transmit and receive data (DTE/IMiK 
data]* the buffer contains timing information, lead change 
information, and special condition characters for protocol 
specific information and errors on the line. 

The DTE and DCE data words have bit 15 set to 1. Each 
DTE/DCE word represents a displayable data character and 
includes six bits of timing information. 

A time mark (lie km ark} Ispjii hi to the buffer hy I he front 
end initially at run time and at intervals during a run. The 
tickmark contains the leu most-significant bits of a 18-bit 
timer in the front end. All other words in ihe buffer except 
for an absolute status word contain the lower six bits. 
Whenever the lower six bits overflow, a tickmark is put 
into the buffer. This information is baud rate dependent. 

The timing is set to a frequency to guarantee a minimum 
of one-character resolution, Each tickmark is to Unwed by 
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Fig. 8. HP 4953A internal data buffer formats. 

an absolute status word which defines the current condi- 
tion of each of the 15 leads, Cursor tinting uses this time 
si amp and the time information included wilh the other 
types of words in the buffer to determine the time between 
any two characters on the display. 

A lead change w r ord is always followed by an absolute 
status word. The lead change word supplies .six hits of 
timing information, the address of the lead currently chang- 
ing, and whether it has gone high or low. 

Some of the special characters are displayable, some are 
nol. The special characters representing I lie Kt;S and start/ 
end flags for bit-oriented protocols are displayable charac- 
ters representing bil sequences brought in from the line. 
Other special words in the buffer can represenl parity 01 
framing errors, in which case I he previous data character 
is set to blink on the display, hut the special condition 
itself is atfi displayed. The special words that represent 
the start of a message for the DDCMP protocol are simply 
information for the system to use f making it easy to display 
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Fig. 9. The Data & State display can 
show four control leads with the 
DTE and DCE data. Ptg. 10 shows 
how the information for this display 
is stored tn the data buffer 
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Fig. 10, Data b after to rma t fo r the Data & State display (Fig 9) 



the messages, but neither affect other words in the buffer 
nor are d is playable themselves. 

The first character put into the buffer is always a 
tickmark, which is always followed by an absolute status 
word, This can be overlaid by new data after I he buffer has 
been filled. When the HP 4953 A has stopped executing 
[receiving data), the pointer to the next available location 
for data can be anywhere in the buffer, and the buffer may 
have filled any number of times, in which case the first 
valid tickmark is determined. 
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A Low-Cost, Portable Field Service 
Protocol Analyzer 

It's menu and file compatible with HP's higher-performance 
analyzers and has many of the same capabilities. 

by Vonn L. Black, Alan Delwiche, Chris L. Odell, and Stephen B. Tursieh 



DIGITAL DATA COMMUNICATIONS pervades the 
business and private sectors of our world so much 
that a truly portable protocol analyzer can be an 
invaluable tool in maintaining such equipment as comput- 
ers, terminals, printers, and moderns. The HP 4951 A Pro- 
tocol Analyzer (Fig. 1) is designed to meet the requirements 
for field service in a single portable test set, With the HP 
495 lA t a user can monitor data transmission, simulate net- 
work equipment, perform bit error rale lesls. and remotely 
transfer data and programs, Customer support and field 
service personnel of service providers and computer or 
communications equipment manufacturers will find this 
compact analyzer useful for datacom network installation 
and maintenance, Communications centers will find its 



monitor and simulate capabilities helpful in diagnosing 
system operating problems, 

The main contributions of the HP 4951 A are high perfor- 
mance, ease of use, and low cost in a highly portable pack- 
age weighing less than 6,5 kg. A menu-driven softkey user 
interface makes it easy to use. One softkey invokes an Auto- 
configure routine that automatically determines a line's 
protocol, data code, speed, error checking, and other pa- 
rameters, The HP 4951 A is menu and data file compatible 
with the higher-performance HP 4953A (see article, page 
4| and HP 4955A Protocol Analyzers, making possible re- 
mote transfers of data, programs, menus, timers, and count- 
ers between members of this analyzer family. 

The built-in CRT display gives the user a choice of dis- 
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play formats. All data monitoring, triggering, and simula- 
tion can be performed at rates up to 19,2 kbps. When 
monitoring bit-oriented protocols, data can be captured at 
speeds up to 64 kbps. The bit error rate test simultaneously 
measures bit errors, block errors, errored seconds, and per- 
cent error-free seconds. 

Architecture 

Fig. 2 shows a simplified HP 4951 A hardware block di- 
agram. The NSC800 8-bit microprocessor is the heart of the 
system, which contains all the makings of a portable per- 
sonal computer. The data link hardware gives the instru- 
ment its ability to analyze digital communications equip- 
mem\ A full keyboard, a 5- inch CRT, arid an integral DC100 
tape drive are other hardware features. The HP 4951 A has 
about the volume and weight of five liters of milk. This 
s ma] loess, necessary for portability, was a driving factor 
in every step of the design. The low power consumption 
of the instrument, 13 watts, is commensurate with its size 
and contributes to its reliability. 

The NSC800 is used because of its low- power CMOS 
characteristics, its enriched Z80 instruction set, and its 
flexible interrupt scheme. B yte- wide CMOS RAM provides 
the instrument with 64 K bytes of memory. 32K nf which 
is for the capture of data and timing information* This 
battery-backed RAM retains information for about six 
months [at room temperature) before the battery needs re- 
charging. The system firmware resides in 104K bytes of 
internal ROM and provides the same menu-driven soft key 
user interface as the more expensive HP 4953A and HP 
4955 A Protocol Analyzers, 

The specialized hardware for the data link control (DLC) 
centers around a serial communications controller IC. This 






( Vertical Sync t 
^ Horizontal Sync] 


CRT 

Deflection 


Half Bright 


Full Bright 


* 1 



Fig* 2. Simplified HP 4951 A hardware block diagram 

part is programmed to support all standard bit rates up to 
19.2 kbps. and both bit-oriented and character-oriented, 
synchronous or asynchronous protocols. Baud rate gener- 
ation and NRZI protocol are also implemented by this chip. 
This dual -channel device allows the DLC to monitor both 
the DTE (data terminal equipment! channel and the DCE 
[data circuit-terminating equipment) channel simultane- 
ously or to monitor one channel while simulating data on 
the other. Physical interfaces such as RS-232-C or RS-449 
are supported by an interim e module. MIL-STD 188-C is 
supported by the R5-232-C module: the user simply selects 
(by soft key) the data to be inverted. 




Fig. 1. The HP 4951 A Protocol 
Analyzer is designed for field ser- 
vice- It has a menu-driven softkey 
user interface, and one softkey in- 
vokes an Autoconfigure routine 
that automatically determines a 
fine's protocols data code, speed, 
error checking, and other param- 
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Fig. 3. HP 495 1 A vertical deflection amplifier block dmgram 

The DLC also provides a high-resolution clock to time 
skimp data or control lead activity for use in timing mea- 
surements, liit error rate tests [BERT] are also performed 
via the DLC. The HP 4951 A is the only member of the HP 
protocol analyzer family that has this feature, which pro- 
vith;s a means of digitally testing the integrity of the phys- 
ical data connection, 

CRT Display 

The green- phosphor CRT displays lfi lines of 32 charac- 
ters each using an 8 x 14-dot character cell and a 7 x 9-dot 
character font. The extra large cell provides underline, 
overbar, and underbar attributes to all fonts. Additional 
attributes implemented in the deflection circuitry include 
half bright, inverse video, blinking, and flashing video. 

The vertical deflection amplifier block diagram is shown 
in Fig, 3. Vertical sync is provided by Ihe CRT controller 
and is synchronized with the horizontal and video timing. 
After duty cycle adjustment, the vertical sync signal drives 
.i dual-slope integrator to create a voltage ramp (sawtooth). 
The gain and centering stage affects the magnitude and 
position of the vertical deflection of the CRT beam. The 
voltage ramp is converted to a current ramp in the voltage- 
to-current converter stage, which drives the vertical deflec- 
tion yoke. For small angles oJ deflect ion, the amount of 
deflection is proportional to the current in the yoke. There- 
fore* a linear current ramp is used to create the desired 
vertical beam deflection. The amplifier does not correct for 
the nonlinearity in the tangential beam velocity which re- 
sults from maintaining a constant angular velocity through 
a varying radius, For the CRT used I he result iog distortion 
is less than 10% and is deemed acceptable, allowing the 
design of the vertical amplifier to be simplified to save 
space, cost, and power. 

The video amplifier (see block diagram, Fig. 4) is de- 
signed for low-power operation. The amplifier shifts the 
voltage level of the dot information provided by the CRT 
controller to a level suitable for driving the cathode of the 
CRT. The amplifier generates levels corresponding to full 
bright, half bright, and blank states, The drive circuits use 
Sehottky diode clamps and speed-up capacitors in the tran- 



ir base circuits for fast switching. Low-power operation 
is achieved by providing a relatively high-impedance dc 
path to the cathode, but a much lower ac impedance for 
the level drivers: this makes it possible to drive the cathode 
capacitance with the speed necessary for crisp transitions 
in intensity (full bright, half bright, or off J. 

While mnsl of the horizontal amplifier circuitry is con- 
ventional, the drive circuit has been greatly simplified. The 
generally practiced method of driving the flyback trans- 
former with a bipolar switch was abandoned in favor of a 
power MOSFET scheme. The FET eliminates the tempera- 
ture dependent base storage time of bipolar devices and 
the transformer base drive circuitry required to turn off the 
saturated transistor quickly. The major benefit, however, 
is the elimination of phase control circuitry by driving the 
horizontal amplifier open-loop, directly from the horizon- 
tal sync signal generated by the CRT controller, while hold- 
ing the overscan to 5% of the total sweep. 

The CRT display consumes only seven watts and requires 
less than 40 square inches of printed circuit board area. 

Mass Storage 

The battery-backed RAM is complemented by ihe addi- 
tional data and menu storage capabilities of the DO 00 tape 
drive, which uses the delta-distance recording scheme and 
HP's standard Logical Interchange Format. Low power, 
small size, low cost, and performance were the overriding 
factors in the design of the tape controller. 

Power is conserved by pulse width modulation of the 
voltage to the motor and by switching off the lamps when 
the motor is idle. Active power consumption of the drive 
is less than 10 watts during fast forward operation and only 
G watts during read/ write, Standby power is abou t 1 00 mVV, 

The tape electronics occupies a printed circuit board 
area of less than 30 square inches and provides double the 
throughput of the HP 49 55 As tape drive. Read/write speed 
is 40 ips at 1 BOO flux reversals per inch. An 8048 microcon- 
troller handles data formatting and control of direct mem- 
ory access to the system memory area. This translates tnto 
less than 3% overhead on the main processor during the 
most demanding run-time data transfers, Each tape car- 
tridge provides about 1 fi times the capacity of the 32K-byte 
data capture buffer. 

The tape controller was originally designed for the HP 
4951 A and has been incorporated in the higher- perfor- 
mance HP 495 3A as welL 
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Fig. 4. HP 4951 A video amplifier block diagram. 
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Fig. 6. Block diagram of a 
hardware implementation of the 
bit error rate test (BERT), 



Power Supply 

A custom switching power supply was designed to pro- 
vide the necessary efficiency in a small area. A commer- 
cially available supply was not practical at the time because 
of the irregularity of the load, most of which is on I lie 
+ 12V supply for the CRT and the tape motor. The HP 
4951A supply switches at 11)0 kHz and provides up to 35 
watts of power (while the tape motor is accelerating) with 
less than Id mV of ripple on the 12V supply, Even with a 
dc-lo-dc efficiency of approximately 85%, it was critical 

thai ill 1 1 lectronics consume as little power as possible. 

The CRT and the tape electronics are prime power coi 
vers in this instrument. 

System Firmware 

As can be seen in Kig, n. only about 10% of the available 
space in the HP 4951 A is dedicated to special hardware 
fur protocol analysis. The instrument is tailored to data 
i mnm mm ,itinns by I he 1U4K byles of resident firmware 
[software stored in ROM). The HP 4951 A not only provides 
Ihe user with a friendly, menu-driven interface similar to 
thai of the HP 4955A. but also provides special measure- 
inenl features and capabilities, These include BERT, Auto- 
configure, and many applications packages. 

The user interface provides 15 menus from which ap- 
proximately 50 parameters may be selected, in addition to 
the Monitor and Simulate menus and the applications. 
Each applications program may contain hundreds of lines 
I fiat cause data to be sent, tested, timed, counted, and so 
on. Five timers and five counters are accessible through 
these programs , just as they are in the larger HP 495:.iA and 
II! 3 4955A. Program flow can be based on the occurrence 
or lack of any combination of up to IVA trigger events or 
interface conditions- The BERT and Auloconfigure me 
of the HP 4951A are not provided in the other two analyz- 
ers. 



Bit Error Rate Test 

One of the functions of the HP 4 951 A that didn't fit in 
the limited amount of hardware space is bit error rate test- 
ing. Instead, this function is implemented in software, 
using the DLC hardware. Performance requirements pre- 
vented a simple implementation of the hardware algorithm. 
necessitating a new approach to the bit error rate test. 

Bit error rate testing involves sending a predefined bit 
stream over a dala communications channel and analyzing 
the data received at the other end of the channel to deter- 
mine the error rate. Fig. 6 shows a block diagram of die 
main elements in a hardware implementation. 

The transmitter is a shift register with certain bits fed 
back to create a pseudorandom hit sequence winch repeats 
every 511 bits, The receiver contains two shift registers 
with the same bits led [jack. A sync register does not have 
feedback bul is used fn compare each bit received with the 
hi I expected, based on the previous nine bits, The 
counter counts the number of consecutive matches between 
expected and received bits. Synch roni nation is achieved 
when nine consecutive received bits match the expected 
values, The comparison register is then loaded with the 
current contents of the sync register, These i ontents are 
the same as those of the transmit register for a given point 
in the bit stream and cause the comparison register to out- 
put the same bit pattern as the transmitter. This becomes 
the reference for comparison against the incoming data. If 
the dala received differs from the output of the comparison 
register, an error is counted 

The straightforward way to implement such a tester in 
software is to simulate each of the three registers, operating 
on one bit at a time. At the top speed of the HP 4951 A 
(19.200 bps), each hi! must tie analyzed in just 52 microsec- 
ini The C; code shown in Pig. 7 for tins implementation 
of the BERT will not run fast enough on a 4-MHz NSCS00. 
In fact, a handcompiled version of this algorithm is much 
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■■* Transmit shift register: next. bit - the next bit to transmit. to 

nexLbit = ((currenLtransmiLstate & >■■ 100) --> B) ((currentjransmitstaie & 0> 10) >> 4); 

currenLtransmiL&tate = (current. transmrt.state < < 1) | next bit; 

/* Receiver synchronization shift register: when 16 valid btts have 
been received, we are synchronized; when 16 invalid bits have 
been received, we are out of sync, */ 
next_sync_brt = ( (currently nc_slate & 0> 100) > .-- 8j ((current_sync_state & ■■ 10) --AY. 
if {next_sync_brt f - recetved.bit) 
{ 
sync_count = 0; 
rf ( + + out_sync_count > 1 6) 



out_sync_count ■ 
ouLoLsync -= 1; 



16; 



etse 



out.sync .count = 0; 
if (+ + sync. count > 16) 
{ 
sync.count ^16; 

ouLof.sync - 0: 

current, receive.slate = current_sync_stata; 



current.sync. state - (currently nc_state << 1) | r eceived.bit ; 

■'* Receiver error checking shift register; received bit - the bit 

just received from the data line, next_receive_bit - expected ^alue. *. 
if (out.of sync - = 0) 
I 
nexLreceive_bit = ({currenLreceive_state & K 100) » 8) ((currenLreceive.state 8.0x10) »$)', 
current_receive_sta1e = (current_recerve_state « 1 ) ) nexLreceive_bit; 
if {next_receive„bit ! - received bit) 
{ 

+ + errorjcount; 

I 



J 



too slow (about 100 jjls per bit), so a new approach was 
taken for the HP 4951 A. 

The hardware implementation uses serial operations, 
while a software approach has ihe advantage of operating 
on eight hits a I a time, Let's look at what happens to I he 
contents of the shift register over the course of eight con- 
secutive shifts. We see i n Fig, 8 that the new value generated 
at each state is shifted into bit QA, and the rest of the register 
is shifted right one bit. Thus, after eight shifts, bits QA 
through QH contain the next eight values that would have 
been generated. The last line of the table shows the formulas 
for each bit. Examining these results we find that we can 
generate the final state by doing an eight -bit- wide exdu- 
sive-OR of bits QB through QH with bits QG t QH, QI T QA, QB, 
QC, QO, and QE, and an exclusive-QR of three bits of the 
result with bits QC. QD, and QE, and rotating the result to 
the correct position, 

A section of ZBO code to implement this algorithm is 
shown in Fig, 9, This code executes in 23,5 jjls on a 4-MHz 
processor, and the code to implement all three registers 
takes less than 100 ja& for eight bits, This Is roughly equi- 
valent to the time for the bit-serial simulation and repre- 
sents an eightfold improvement in throughput. 

Such careful attention to optimizing algorithms is the 
key to the performance of the HP 4951 A and also shows 
up in the data capture and analysis software. 



Fig. 7. C code for a software im- 
plementation of the BERT hard- 
ware shown in Fig. 6. This approach 
is too s!ow for the HP 4951 A 

Autoconfigure 

What do you do when you want to monitor a data line, 
but you don't know anything about the data? Is the protocol 
SDLC? Is the data synchronous? Is the data code ASCII? 
When the user presses the Auto Configure soil key on the top- 
level HP 4951 A menu, an algorithm called Autoconfigure 
uses the data it receives on the line to determine- — often 
statistically — the protocol and other parameters, These pa- 
rameters are displayed in a setup menu, and the HP 4951 A 
automatically goes into the Run mode and begins monitor- 
ing. The main advantage of Autoconfigure is that it allows 
even novice users to monitor a data I me. 

How does Autoconfigure decide what's on the line? It 
looks for the simplest parameters first and then uses this 
information to look for the more complex parameters. First, 
it J iiids the baud rate by measuring the time between trans- 
itions on the data line* This bit time is measured over a 
large number of bits and the lowest bit time is used. Using 
this method, Autoconfigure can measure baud rates up to 
19.2 kilobits per second. 

After the baud rate is found, the next step is to determine 
whether the data is synchronous or not. A transmit cUn :k, 
supplied by the DCE or the DTE, is required to transfer 
synchronous data. If there is a clock, a timer is used to 
determine if a clock pulse is virtually equivalent to a bit 
time, as previously found. If so, Autoconfigure looks for 
synchronous protocols, such as SDLC or Bisync. Otherwise. 
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Fig. 8* Bt- son* 

luring eight consecutive 
shifts The HP 4951 A BERT al- 
gorithm generates the finai $me 
by performfrtg two excIu$fve-OH 
operations and a rotation, 



it looks for asynchronous protocols, such as character asvnc 
or SDLC-NRZL 

Autoconfigure tries one synchronous protocol at a time. 
If it finds the flags or sync diameters it is looking for, the 
protocol is considered found and Autoconfigure begins 
looking for the data code and other parameters. It looks for 
synchronous protocols in the following order: 

1. Bit -oriented protocols or BOPs (e.g +1 SDLC), Autoconfi- 
gure looks for7E flags and a good CRC-CCITT error check, 

2. Bisync. Autoconfigure looks for standard sync characters 
(e.g., 32H 32H). 

3 . Olher character-oriented protocols. Autoconfigure looks 
for nonstandard sync characters, [e.g., Transcode's 3AH3AH 
with parity I, 

4. IPARS. Autoconfigure looks for the 3FH 3EH pattern- 
When Autoconfigure looks for asynchronous protocols, 

it tries SDLC-NRZI first. It searches for 7EH flags and a good 
CRC-CC3TT error check- If these are not found* Autoconfig- 
ure tests for asynchronous data by first trying to frame on 
5-bit characters. If too many framing errors occur, I he next 
frame size is Fried until an acceptable tmme size is found 
or until the maximum frame size has been tried, 

The data code is determined in different ways For bit- 
oriented protocols, ASCII is chosen if the miist-si^nilit .ml 
bits of the characters are zeros; otherwise, EBCDIC is cho- 
sen. For Bisync and other character-oriented protocols, the 
data code is often determined by the i I >n BS pO tiding sync 
characters (e,g, t EBCDIC uses 32H 32H). For asynchronous 



protocols, the frame size is instrumental in determining 
the data code [e.g., Baudot is the data code chosen for 5-bit 
frames], 

Autoconfigure users should be aware of certain features 
that may affect them. First, Autoconfigure always selects 
SDLC for bit-oriented protocols. Monitoring will always be 
correct except in some cases of X,25 orHDLC with extended 
address and extended control, Also, whenever Autoconfig- 
ure sees a character-oriented protocol, including Bisync, 
it displays the parameters on a Char Async Sync setup 
menu, Other parameters Autoconfigure may find, if applic- 
able, include a transparent t^xt character, the bit sense, 
and the error-detecting code. 
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Remote Monitoring and Control of 
Semiconductor Processing 

This addition to HP's Semiconductor Productivity Network 
acts as a host computer to IC processing equipment, 
providing remote control and data gathering for fabrication 
personnel. 

by Wesley H. Higaki 



THE INCREASING FABRICATION COMPLEXITY, 
shrinking device geometries, and larger chip sizes 
of VLSI circuits are requiring mom arid more automa- 
tion to provide acceptable yields and adequate control of 
process parameters. Automated process monitoring and 
control can provide exact duplication of processing steps, 
accurate measurements of the results, and precise adjust- 
ments to improve the process, 

Automation is common to some degree in modern 
semiconductor processing and measurement equipment. 
Microprocessors and minicomputers control the process 
steps in most wafer processing systems (diffusion furnaces, 
plasma etchers, ion im planters, etc.] by using closed-loop 
feedback with stored "recipes** or process programs and 
loop coefficients, This reduces mechanical complexity 
(fewer switches, relays, etc] and minimises the need for 
human intervention during the process sequence. If a suit- 
able interface to an external computer system can be pro- 
vided, such process equipment can be controlled and mon- 
itored remotely. 

Defining, creating, and storing recipes and then applying 
them to computer control allows greater repeatability of a 
process step. Like a computer program, process programs 
yield greater control over the quality of the output once 
the programs have been qualified, A computer-controlled 
piece of equipment fed the same program over and over 
will yield almost exactly the same results each time; with 
manual control, the results can be unpredictable, Computer 
control also allows for easy monitoring and recording of 
the process. Since closed-loop feedback control relies on 
monitoring capabilities, storing and analyzing the moni- 
tored data becomes the next logical step. 

Equipment controllers are designed to monitor and con- 
trol a process step. They have limited data storage and 
computing capabilities. They also have a very narrow view 
of the overall integrated circuit fabrication process. Indi- 
vidually, each piece of process equipment can optimize 
and control the process step for which it is responsible, 
but cannot correlate the data it collects with the data other 
pieces of equipment have collected. To do this, a host com- 
puter system is required. 

PC-10: Equipment Monitoring and Supervision 

PC- 10 is a recent addition to HPs Semiconductor Produc- 
tivity Network (SPN. see Fig. 1). This product (Fig. 2] acts 



as a host computer system for processing equipment. PC-10 
provides the capability to monitor and control semiconduc- 
tor processing equipment remotely. Its greatest asset is that 
it provides the capability to store and download recipes to 
the appropriate system at the appropriate time. This feature 
alone increases equipment versatility and can reduce pro- 
cessing errors dramatically. From the PC-10 system, a user 
can request equipment status, store measurement data, re- 
motely control equipment, store and restore calibration 
data, and store and restore recipes. Equipment-generated 
alarm conditions are recorded and reported. 

PC-10 acts as the central node in the equipment network 
to gather all of ihe data from the equipment and feed it 
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Fig, 1, HP's Semiconductor Productivity Network is a collec- 
tion of hardware and software, products designed to aid micro- 
electronic product fabrication personnel in controlling, 
monitoring, improving, and managing many of the levels of 
the complex manufacturing process 
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Fig, 2. PC- f0, an SPrV product 
addressing levels 1 and 2 in Ftg. 
7 and coupled to IC-10 in /eve/ 3. 
a//ows toe user to access fabrica- 
tion equipment for checking its 
status, gtving it a new recipe, mon- 
itoring process values, and control- 
ling it without having to enter the 
fab area Connections to the equip- 
ment are accomplished through 
the use of special message trans- 
lators interfacing with SECS ports 



miUj the SPN system. Process engineers can monitor their 
processes much more precisely by having the equipment 
report events to POl for recording in material and equip- 
ment history' lugs. Once the data has been gathered, en- 
gineers can use other SPN tools to correlate the data bom 
one step in the process with data from other (previous) 
steps. This gives the process engineer overall visibility of 
the process that could not be obtained easily without a 
host computer system. 



The ability to store and download processing recipes 
ensures not only that the specified operation is performed, 
but that any engineering changes to these recipes are 
applied uniformly to any affected operation. Since PC- 10 
is the central node in I he network in charge of maintaining 
recipes, engineers are assured that the latest version of the 
recipe is downloaded to the equipment. 

Equipment monitoring* through PC- 10* gives engineers 
a window into the fab area from their offices (Fig. 3). They 
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Fig. 3. Typical SPN display screen 

using PC- 10 to access the status 

of a diffusion furnace. 
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<;an monitor the progress of their processes and their equip- 
ment at remote SPN terminals. Through PC-10 they can 
also review all of the history information that has been 
collected from the equipment 

Data Communications 

Data communications is a major part of PC-10 in two 
areas. PC-10 uses DS/3UQ0-1OGG to link the SPN HP 3000 
Computer System with HP 1000 Computers, which act as 
real-time network nodes. PC-10 also relies heavily on the 
SECS communications standard (see box on page 33) to 
link the HP 1000 Computers to the process equipment, 

[lie DS/3000-1000 link allows PtMO to use the real-time 
capabilities of an HP 1000 to interface processing equip- 
ment. User transactions initiated on the HP 3000 through 
the SPN transaction handler are transmitted down the DS 
line to the HP 1000 for processing. This link is useful for 
functions such as automatically downloading a recipe 
when a tracked material lot arrives at different pieces of 
equipment. 

PC-10 has applications sol! ware on top of the process-to- 
process community I ions capabilities in DS/3000-1000. 
These applications have the intelligence to recover from 
any soft DS failures transparently to all of the users on the 
system, PC-10 also has the capability to link multiple HP 
1000 Computers to a single HP 3000 central node. 

Communication with the process equipment is the key 
to monitoring and supervision, To communicate with each 
of the different types of process equipment, PC-10 relies 
heavily on the use of the equipment manufacturing indus- 
try's communications standard. The implementation ol this 
standard by process equipment manufacturers and PC-10 
has made connecting the equipment to a remote monitoring 
and control system a much simpler task. 

History of PC-10 

PC-10 has essentially I wo roots; the tightly integrated 
SPN family of software packages and I he process control 
system (PCS] developed and used by HP Laboratories. 1 
PC- 10 is designed to integrate w r ith the rest of the SPN 
products such as IC-10, EN-10, and EA-1D, 

IC-10 is (he major tracking product of SPN. IC-10 is based 



on the HP 3000 Computer using Image data bases, one for 
parameter data and one for production data. Its data bases 
define the location-level tracking of material (wafers) 
through the process. A location is a general area in the 
fabrication area such as diffusion or photomasking* Since 
PC-10 addresses individual pieces of equipment and not 
general locations, operation-level tracking has been de- 
veloped to subdivide locations into discrete equipment op- 
erations. EN-10 is used to collect measurement data man- 
ually for analysis by EA-10. 

Between IC-10 and operation-level tracking, process en- 
gineers can completely define the flow of material through 
the fabrication area. When material is tracked through this 
process to a particular piece of equipment which is linked 
via SECS to PC-10, the proper machine instructions can be 
loaded and the process can be monitored from any SPN 
terminal. Measurement data collected by PC-10 frojji \\u- 
equipment is stored in the SPN production data base for 
analysis by EA-10, 

PCS was developed by HP Laboratories' Integrated Cir- 
cuit Processing Lab (JCPL) to track material through oper- 
ations with the capability of transferring the machine in- 
structions to the processing equipment, specifically a 
Thermco diffusion furnace with minicomputer controllers, 
This system w r as based on an HP 1000 using an internally 
developed data base and communicating with the furnaces 
using a forerunner of SECS. Many HP 1C facilities now use 
some version of PCS to operate a portion of their fabrication 
areas, The problems with PCS are that it does not provide 
the complete solution SPN does, it is un sup portable as an 
external product, and it was designed for communicating 
with only the Thermco furnaces. 

To be successful in the marketplace, PC-10 had to address 
two major issues: integrate w p ell with SPN and interface 
with many different kinds of semiconductor processing 
equipment. 

Interfacing Equipment 

To automate a complete IC fabrication area T PC-10 must 
be able to communicate with many different types of equip- 
ment built by many different manufacturers. Our goal has 
been to develop interfaces easily and quickly, w r hich means 
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Fig, 4. Translator flow diagram 
New equipment ts added easily to 
PC- TO by simply developing the 
appropriate host-to-equipment and 
equipment- lo-host tables tot the 
associated SECS It data streams 
Examples are shown lor stream 2 
function 14 and stream 2 function 
66 messages (i.e.. S2F14 and 
S2F66). 
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avoiding writing custom software to fit all of the idiosyn- 
crasies of individual processing systems. Instead. K.MH 
handles IC process equipment by separating it into general 
classes, SECS II (see box below) is a mandatory prerequisite 
of the equipment before an interface to PC-10 can be 
developed. 

HP's approach to interfacing is to survey a representative 
number of pmressing systems with in a class to develop a 
generic model. A class is a group of equipment sy> 
that operate similarly and perform the same general I 
tions so that the communications requirements look the 
same to PC-1Q\ The assumption is that each piece of equip- 
ment in an equipment class supports a subset of the SECS 
II data streams and functions that PC-1U supports for that 
class. We also assume that the order of the messages, which 
is not defined by SECS II, is generally the same for all 
equipment in that class* To date we have encountered 
hatch, metrology, serial, and material handling equipment 
We expect that this list will grow as we begin to explore 
the use of PC-10 for remotely controlling and monitoring 
other types of equipment. 

Batch processing systems, such as diffusion furnaces, 
process wafers in large quantities (batches). The primary 



SECS 

The semiconductor process equipment manufacturers have 
identified the need for the?r equipment to .communicate With a 
larger host computer system and developed the Semiconductor 
Equipment and Materials Institute (SEMI) Equipment Communi- 
cations Standard (SECS). SECS defines parts of an seven ISO 
open system interconnect (OS I) communications layers, SECS I 
incorporates the use of RS-232-C cabling and pin definitions and 
a relatively simple line protocoi SECS II defines messages to 
request and send status information, transfer recipe data, report 
alarm conditions, send remote equipment control commands. 
and handle material transfer, 

SECS I uses a simple ENQ-ACK handshake across an RS-232-C 
line with checksums at the end of each message SECS I also 
defines time-out intervals between handshake responses, indi- 
vidual message characters, and message responses, Message 
headers are defined in SECS I to include equipment identifiers, 
message identifiers, message block numbers, and other system 
information 

SECS H defines message types, format, content, and direc- 
tions SECS streams are groups of messages assigned to a 
general set of equipment functionality. Within each stream the 
individual messages are assigned function numbers. For exam- 
ple, SECS stream 1 function 5 (abbreviated S1F5) «s a formatted 
equipment status request, and stream 1 function 6 is the reply 
with the status information Similarly, stream 7 function 5 is used 
to request the transfer of a process recipe and stream 7 function 
6 is used to transfer The recipe. SECS II also defines whether a 
reply is required or not, the message content and format (includ- 
ing data item definition headers), and whether a message may 
be used from equipmeni-to-host and/or host-to-equipment 

A major limitation of the SECS standard is that it defines mes- 
sages and their content only: it does not define howthe messages 
are used together to perform a function Equipment manufac- 
turers are left to decide what messages to use to perform func- 
tions that were performed manually before. This, of course, makes 
if difficult to develop translators for external systems to communi- 
cate with such equipment. 



characteristic is that once a batch has started processing, 
no more wafers can he ad tied until the process sequence 
has run to completion. PC-10 will download only am 
ipe to the batch station when the batch is tracked in and 
no other batches will be allowed in until the first batch is 
done, 

itrology systems are classified separately because they 
provide certain measurement data to PC-10, PC-10 supports 
SECS II stream 6 messages, which handle the transfer of 
measurement data to the host system for this class of equip- 
ment. Examples are line width, film thi \)6 defect 
measuring devices. Wafers passing through these stations 
are not processed, but are merely measured to determine 
the effectiveness or accuracy of previous process steps. 

Serial processing handles wafers one at a time. Wafers 
from one lot may he entered into the equipment for process- 
ing before the preceding lot has been completed. Photo- 
lithography wafer track systems are a prime example of 
serial equipment. PC-10, to ensure that the proper recipe 
is executed for each kit. must check to see if the recipe 
already executing is the proper recipe fur the next lot. If 
not, it must download the new correct recipe at the proper 
time for beginning processing of the new lot. 

Material handling requires an entirely different set of 
messages, since material handling systems are responsible 
only for transporting the wafers from one station to another, 
PC-10 instructs the material handling system to take a lot 
or a group of lots to a particular piece of equipment. Exam- 
ples ol material handling systems include robots or tracks 
used to move the wafers through the fabrication area. 

The challenge we face when we address a new class of 
equipment to develop our models is to perform an adequate 
survey of such equipment on the market and develop an 
accurate, yet general model of how these pieces of equip- 
ment operate. This requires that we understand how the 
equipment works, what it is used for, and how PC-10 
should interact with it. In the past we have reviewed com- 
munications specifications from the vendors and received 
training on how to operate the equipment. 

Once our models have been developed, it becomes B 
matter of evaluating equipment to see if they fit the model. 
II a piece of equipment fits the model, then we must resolve 
any differences in the equipment's SECS message formal 
and content PC-10 does this at the lowest level of its soft- 
ware — the message translator. 

Translators 

The translators convert SECS messages as interpreted by 
the equipment into PC-10 interpretable messages, This in- 
cludes translating binary values into ASCII representations 
and vice versa, resolving data item length differences, 
masking off unneeded data items, and formatting data for 
displays or data base records. 

The translators are table-driven. Thus, to interface a new 
piece of equipment, ail that must lie done is to generate a 
new table and pass it to the translator program (Fig. 4). No 
new code is written. This technique greatly reduces the 
time needed to develop a new interface compared to having 
to custom-code the interface. 

The price we pay for this short development lime is an 
interface lh.il may not lake advantage of all of the features 
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Fig. 5, SECS !i formats for (a) messages and (b) data items. 

a piece of equipment has to offer or may make operating 
the equipment more awkward than if custom software were 
written. However, with only the translators changing for 
each different piece of equipment, the other software layers 
remain unchanged and so do not have to be updated 
whenever new equipment is added to a fabrication area. 

The first step in building a translator is to review the 
equipment vendor's SECS implementation specifications 
to see if the general interpretations match those of PC-10; 
that is, there is a message comparable to that of PC-lU's for 
every critical message. Critical message sets differ from 
equipment to equipment, A measurement data report is 
critical to film thickness measuring devices, Recipe transfer 
messages are critical for furnaces, because that capability 
is what makes the interface useful. 

SECS II defines a 10-byte header and message bodies 
(see Fig. 5). Within the 10-byte header are the device ID 
fbytes 1 and 2), message type (stream) and function (bytes 
3 and 4), message block number (bytes 5 and 6), and system 
bytes (bytes 7 through 10). The translator is used to resolve 
the differences in the interpretation and usage of stream 
and function numbers between PC-10 and the equipment. 

Within the SECS II message body* there can be several 



data items. Each item is preceded by a formal header that 
describes the item. This header is a 2-to-4-hyte item de- 
scriptor. The first byte contains the data format [i.e., ASCII 
or binary] and a 2 -bit length byte count, The length byte 
count indicates the number (1 to 3] of following bytes 
that contain the length of the data item (Fig. 5b). The 
translator resolves the implementation and the equipment 
interpretation, 

The translator resolves differences in the PC-10 and 
equipment vendor's interpretations of SECS II streams, 
functions, and data item formats by using a translator table 
for host-to-equipment messages and another table for 
equipment-to-host messages (Fig. 4), Each table maps the 
appropriate equipment message stream and function to an 
equivalent PC-10 stream and function. This mapping is not 
necessarily one-to-one* 

A variant fable is included to provide the capability for 
a one- to-many mapping of messages. The first item in the 
message is used to determine which stream, function, and 
message body format are used* The variant table entries 
contain data (either ASCII or binary) to be compared with 
the message data. 11 a match is made, then the mapping 
pi i try with the corresponding variant number is used to 
format the translated messages. 

Each table also maps, item by item, the data format and 
length to be sent. Each line in the host-to-equipment map 
defines the format and length of the individual data items 
from PC-10 to the translator and the format and length to 
be used when the message is sent to the equipment, The 
equipment-to-host map contains the description of the data 
items as they will be passed to PC-10. 

The table entries have the ability to pass the data through 
the translator without reformatting. This is a feature PC-10 
uses to handle calibration and recipe data, since PC-10 will 
only store and deliver recipe data as the equipment pro- 
vides and expects it. 

The table entries can also mask off data items as neces- 
sary. This is useful when PC-10 provides data items that 
the equipment does not use or expect in its messages. 
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